Re: Is this expected behavior or not

[Shark8 <onewingedshark@gmail.com>]

On Saturday, March 16, 2013 1:41:27 AM UTC-6, Dmitry A. Kazakov wrote:
> On Fri, 15 Mar 2013 22:52:02 -0700 (PDT), Shark8 wrote:
> 
> > True; but there could be some more interesting cases, say, for Ada 2020.
> > Something like:
> > 
> > Abstract Type UNIVERSAL_STRING(Element : UNIVERSAL_CHARACTER) is 
> >     Array(Positive Range <>) of Element'Type;
> 
> That would not work. I presume that here you want to create a root type for
> the class of string types and get at the members of the class (specific
> types like Wide_String) using a constraint. The problem is that string
> types must have different representations. The mechanism of constraining
> does not support. 

Kind of, but not really; I'm thinking a sort of combination of generics and classes (in the general sense, not the OOP-sense): a way to specify a general behavior for a type-class. (i.e. having the ability to fully-specify things like attributes [not really shown in this example].)

> Thus either subtypes will have same representation or you
> won't have a class.

I'm thinking of it more in the terms of generic operations: independent of representation.

> Another problem is that string types must have more 
> than one interface to deal with UTF-8 etc. An UTF-8 string is *both* an
> array of Wide_Wide_Character (= Unicode code points) and an array or
> sequence of Character (octets).

Ah, things get tricky here; Unicode is kind of a bear when you consider 'characters' because its codepoints aren't necessarily characters. An example would be the so-called "combining characters" which you can use for things like accents or ZALGO-text. (See these, respectively: http://en.wikipedia.org/wiki/Combining_character and, http://eeemo.net/ )

An important implication of this is that string search/manipulation becomes MUCH more complex. (`+a = à) means that you now have to search for multiple possibilities when your target is "à" -> the single-glyph code-point, or the combining-character points... and that's not taking into consideration whether you should consider a & à & (a+diacritic) to be the same or unique entities -- and casing is another combinatorial factor.

It would be a big mistake to assume character = code-point when dealing with Unicode.

> An UTF-16 string is an array of Wide_Wide_Character and an array of Wide_String.

UTF-16 is perhaps the worst possible encoding you can have for Unicode. With UTF-8 you don't need to worry about byte-order (everything's sequential) and with UTF-32 you don't need to decode the information (each element *IS* a code-point)... but UTF-16 offers neither of these.

------------------------------------------------------

I guess what I'm trying to say is that if we did it right, we could modify/expand the type-system so that something like UNIVERSAL_INTEGER could be made/explicitly-specified. (And if done extremely well, something like UNIVERSAL_STRING where perhaps the only thing differentiating the strings would be the 'instantiation' with their proper character-type* and manipulation-functions.) -- GNAT already has the 'Universal_Literal_String which works in either of the following lines:

Ada.Wide_Wide_Text_IO.Put_Line( Ada.Numerics.Pi'Universal_Literal_String )
Ada.Text_IO.Put_Line( Ada.Numerics.Pi'Universal_Literal_String )

In any case; I think it worth considering not just outward/downward expansion of the language, but inward/upward [unification] as well.