Re: Ada.Locales pseudo-string types

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

On Wed, 8 Aug 2012 02:32:53 -0700 (PDT), Marius Amado-Alves wrote:

> I agree that letting contracts contain dynamics stuff brings us dangerously close to weak typing.
> 
> But let me recall that the original case is all static: we want to convert from
> 
>    type Language_Code is array (1 .. 3) of Character range 'a' .. 'z';
> 
> to
> 
>    type String is array(Positive range <>) of Character
>       with Pack;
> 
> Nothing could go wrong in this case.

That depends on the way you define wrongness. To me it is already wrong
because types are different. Note that from my POV being structurally
equivalent means nothing. Type is a set of values and operations. What
operations are defined on Language_Code? Are they same to ones of String?
If so, then conversion is possible. But I don't know it. It is not the
language business to determine.

Moreover, for non-tagged types it is broken anyway, because any
user-defined operations are not primitive and get ignored by the compiler
where you expected that least. There really should be no types without
classes and primitive operations.

If I ran the circus I would allow means to make Language_Code a proper
subtype of String while retaining necessary constraints.

Furthermore, regarding the points J-P. made, it is important to have
subtypes differently implemented. That would leave the issues of
optimization to the programmer's discretion. You would define a conversion
from Language_Code to String and use the former with any operations taking
in-String. You would declare a backward conversion and would use it with
all out-String operations. Two conversions more and you would be able to
use String with Language_Code operations.

> Or in the general case of converting from subranges to fullranges, no
> matter how deep in the type structure. If the structure is the same, and
> the operand has a subrange (or a match) in the same place as the target,
> then please (dear Ada 202X) convert it.

This is what I certainly disagree with. Structure is an implementation
detail.

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