Re: Community Input for the Maintenance and Revision of the Ada Programming Language

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 31/08/2017 14:49, Jacob Sparre Andersen wrote:
> Dmitry A. Kazakov wrote:
> 
>> You need a view of a string as an array of code points / unicode
>> characters *and* another view as an array of encoding items,
>> e.g. octet for UTF-8 or word for UTF-16 etc.
> 
> But the encoding stuff is (mostly) on the out-side of the application.

Not really. E.g. parsing is done in octets for obvious reasons. That was 
the reason why UTF-8 was designed this way.

> I don't mind having routines for mapping to and from various encodings,
> but the encoded types should not have character or string literals, they
> should just be arrays of octets with certain characteristics.

I don't understand this. What is the use of a string type without 
literals? Unbounded_String is a perfect example why this does not work.

It is all about having an ability to choose a representation (encoding) 
rather than getting it enforced upon you by the language. It is no 
solution if you simply create yet another type with the required 
representation losing the original type's interface and forced to 
convert forth and back between two types all over the place. This mess 
does not deserve consideration. We have it aplenty: String, Wide_String, 
Unbounded_String, char_array, chars_ptr ad infinitum.

> Don't worry so much about the encoding-view.  Push the encoding troubles
> to the edge of your application, and work in a consistent form inside
> the application.

Many, if not most, applications never care about code points. 
Applications deal with substrings starting and ending at the boundary of 
a code point. For them it is no matter if the substring is a chain of 
code points or a chain of encoding items.

>> You cannot handle this in present Ada.
> 
> You can, if you harmonize to a single encoding for the character and
> string view, and only see specific encodings as serializations of
> (subsets of) the general character and string types.
> 
> The places I expect to see trouble is if some source text assumes that
> Standard.Character and Interfaces.C.char are the the same.

It should assume Standard.Octet and Interfaces.C.char same. You simply 
cannot drop either encoding items or code points. It would never work.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de