Re: Ada and Unicode

["Randy Brukardt" <randy@rrsoftware.com>]

"J-P. Rosen" <rosen@adalog.fr> wrote in message 
news:t2knpr$s26$1@dont-email.me...
...
> It was felt that in practice, being too strict in separating the types 
> would make things more difficult, without any practical gain. This has 
> been discussed - you may not agree with the outcome, but it was not made 
> out of pure lazyness

The problem with that, of course, is that it sends the wrong message 
vis-a-vis strong typing and interfaces. If we abandon it at the first sign 
of trouble, they we are saying that it isn't really that important.

In this particular case, the reason really came down to practicality: if you 
want to do anything string-like with a UTF-8 string, making it a separate 
type becomes painful. It wouldn't work with anything in Ada.Strings, 
Ada.Text_IO, or Ada.Directories, even though most of the operations are 
fine. And there was no political will to replace all of those things with 
versions to use with proper universal strings.

Moreover, if you really want to do that, you have to hide much of the array 
behavior of the Universal string. For instance, you can't allow willy-nilly 
slicing or replacement: cutting a character representation in half or 
setting an illegal representation has to be prohibited (operations that 
would turn a valid string into an invalid string should always raise an 
exception). That means you can't (directly) use built-in indexing and 
slicing -- those have to go through some sort of functions. So you do pretty 
much have to use a private type for universal strings (similar to 
Ada.Strings.Bounded would be best, I think).

If you had an Ada-like language that used a universal UTF-8 string 
internally, you then would have a lot of old and mostly useless operations 
supported for array types (since things like slices are mainly useful for 
string operations). So such a language should simplify the core 
substantially by dropping many of those obsolete features (especially as 
little of the library would be directly compatible anyway). So one should 
end up with a new language that draws from Ada rather than something in Ada 
itself. (It would be great if that language could make strings with 
different capacities interoperable - a major annoyance with Ada. And 
modernizing access types, generalizing resolution, and the like also would 
be good improvements IMHO.)

                                               Randy.