Re: Musing on defining attributes and the ability to define an "abstract type X"-interface.

[Shark8 <onewingedshark@gmail.com>]

On Thursday, July 20, 2017 at 2:12:08 PM UTC-6, Jacob Sparre Andersen wrote:
> Shark8 wrote:
> 
> > No, an array of ASCII is *NO* compatible with an array of Latin-1; the
> > first is 7-bit data, the latter is 8-bit data.
> 
> Depends on whether you worry about encoding or just consider ASCII and
> Latin-1 as character sets.  If you're just thinking of character sets,
> consider:
> 
>    subtype Latin_1_String is Wide_Wide_String
>      with Dynamic_Predicate => (for all C of Latin_1_String => Character'Val (C) < 256);
> 
>    subtype ASCII_String is Latin_1_String
>      with Dynamic_Predicate => (for all C of ASCII_String => Character'Val (C) < 128);

This has the implicit idea of a super-set [in this case Latin-1] which is fine, until you get into the representation territory. [Representation isn't /quite/ the same thing as encoding.]

To illustrate, a proper and strict ASCII string would be:
    Type ASCII_Character is Character range Character'First..Character'Pred( Character'Pos(128) );
    Type ASCII_String is Array(Positive Range <>) of ASCII_Character
     with Component_Size => 7, Packed;


But this isn't *REALLY* about strings in and of itself, that's just where it becomes most obvious, it's rather about being able to:
 (a) turn the current implicit hierarchy into an explicit one,
 (b) in a manner that will allow user the usage,
 (c) especially in the area of uniformity, and
 (d) also permits the [re]definition of our current
     language type-classes/-kinds/-classifications.

IOW, what I want to do is leverage the language's underlying concepts, making them explicit, and using *THAT* to unify/define what is already (in some sense) required... like how universal_integer attributes require a bignum package, but the language doesn't require its exposure.