Re: IBM 437 encoded String to UTF-16 Wide_String

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

On Wed, 28 Nov 2012 12:31:35 +0100, Georg Bauhaus wrote:

> On 28.11.12 10:58, Dmitry A. Kazakov wrote:
>>  When I mentioned Wide_Wide_String I meant an array of code points. The
>> logical view of *any* string type is array of code points. The only
>> difference between different string types is in the constraints put on the
>> code points. E.g. String has code points 0 to 255. IBM_437_String would
>> have a non-contiguous set of code points etc.
> 
> What is a non-contiguous set?

A convex set in this case, i.e.:

for code points x,y,z, such that x<y<z if x,z in S then y in S

> In case of differentiation by sets of code points, I'd rather
> have an honest type Unicode_String and---if we are already
> fixing the language---put everything that has {Wide_}String
> in its name in Annex J.
> 
> But then, consider
> 
>     type Index is range 1 .. 12;
> 
>     type R is ('I', 'V', 'X', 'L', 'C', 'D', 'M');
> 
>     type N is array (Index range <>) of R;
> 
> A string of R, named N here, is just fine. In fact,
> 
>     Year : constant N := "MCMLXXXIII";
> 
> has a valid literal, and the year so written is not of any of
> the standard string types. The definition of type R actually
> implies a codespace, and, for example, Character'('V') or
> Wide_Character'('V') have no role in it, irrespective of
> any accidental overlap in encoding or representation or
> position.
> 
> So, which by force should type N be in Whatever_String'Class?

Per inheritance:

   type N is
      new Wide_Wide_String
      and array (...) of R;

>>> As a practical alternative, why not add a generalized
>>> std::valarray<type T = (<>)> to the language instead
>>> of fixing it?
>>
>> No idea what this is supposed to mean.
> 
> Call it
> 
> generic
>     type Element_Type is ...
>     type Index_Type is ...
> package Ada.Containers.Tuples is
>     ...
> 
> and make it have standard container operations, extended as needed.

It does not solve anything. The problem is not construction of a container
type. It is the relation of the obtained type to the string interface. The
string interface is an array of code points. The container must implement
this interface in order to be a string. All strings must implement this
interface, this is why they are called "strings."

> The idea is that if Element_Type is ordered scalars, and if container
> operations provide for writing algorithms efficiently, then
> that's a more practical way of having strings of anything
> than, say, finally removing "tagged" from the language and make
> every type be in some 'Class.

Every type is in more than just one class, trivially.

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