Re: Ada.Characters.{Wide_}Latin_9 should be deleted

[dewar at gnat dot com (Robert Dewar)]

> Would you agree with the principle that you shouldn't hardcode into the source
> something that the user needs to be able to change at runtime? That's what 
> Ada.Characters.Latin_9 does - it hardcodes Latin 9 into the source code, when
> what the program should use the locale character set. It's not stylistic 
> judgement; it's the inherant constraints of writing multi-cultural code. There
> are many solutions, but the one most consistent with what Ada already does is
> to use Unicode,
> 
> 

We are not in the business of telling people how to write code. You may have
a mission to make everyone use wide charadter sets (the use of multi-cultural
smacks of such a mission) and that's fine, but it is quite inappropriate to
remove useful features in an attempt to force programmers to program the way
you think they should. 

The point is basically this. Ada is designed to most naturally use Latin-1,
and the vast majority of Ada programs use Latin-1, and it's just fine. Yes,
for your multi-cultural mission, this is bad, and those programs should be
rewritten to use some form of Unicode, but as I say that's not our business
nor is it the business of Ada to be pushing this approach. All we should do
in Ada is to enable people to use 16-bit Wide_Character if they want.

But Latin-1 is now obsolete and for practical purposes replaced by Latin-9.
If Ada was being designed today, then it would be based on Latin-9 rather
than on Latin-1. Since the Ada standard specifically invites us to add
character sets, it is natural to add Latin-9 to reflect this update. I
would expect the new version of Ada to adopt Latin-9 as the base set or
at least consider this (it might be rejected due to upwards comaptibility
problenms).

What you seem to want to do is to use the leverage of the introduction of
the Euro symbol to force people to move to 16 (or 32!) bit character sets,
but that's definitely not helpful to most people writing programs in 
Europe today. 

Looking at wide_character, a basic assumption is that the first 256
positions of Wide_Character correspond to Character. A lot of code
depends on this, so that is why it is natural to introduce 
Wide_Latin_9.

So I definitely do NOT agree with your statement. The idea that all programs
should be able to use the local character set is a wish you have as part of
your multi-cultural mission, but it is unrealistic, and in any case, as I
say, it is not the proper place of Ada compiler producers to be telling
customers this sort of thing. Ada is NOT designed to force people in this
direction, and you have no business distorting Ada to do this.

As for 32-bit Wide_Wide_Character, we should be a little careful. If we
add this to the standard, it is a definitely non-compatible change because
of the special status of visibility of standard. In other words if someone
has Wide_Wide_Character defined in a package today, they can get seriously
messed up by the introduction of this name in Standard. So most likely
this type shoudl NOT be added to Standard, but rather introduced in a
separate package.

I would think the right thing here is to design this package, and then try
to get it approved through the standard Ada comment procedure as an approved
part of the next standard addendum. Meanwhile, providing that it is a 
separate package, I don't see any objection to adding it, but to refcognize
it as a built-in type seems to me to be a language extension that should
get general acceptance before being implemented. Of course this language
extension would have to be under control of -gnatX in any case (or its
introduction would constitute a non-conformance).

So anyway, rather than just produce a patch, I think the first thing is to
propose a design for discussion (we never implement new features without
first discussing the design, especially if they are actually or in effect
language extensions.