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

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

On 2017-07-20 18:37, Shark8 wrote:
> On Thursday, July 20, 2017 at 1:52:14 AM UTC-6, Dmitry A. Kazakov wrote:
>> You need along with the array type:
>>
>> 1. Index type
>>
>> This is for 1D arrays. For ND arrays you need types in-between (tuples
>> of indices) and sub-arrays.
> 
> Making a specialized interface for 1D arrays seems, well... stupid,
> especially when we're talking about such a change to the language so as
> to easily open up the full generality.
> 
> IOW, why have just "index type" for an array? At this point you're
> just using generics, albeit with a different
> name. We need an array of indices of type, but not just any type,
> discrete-type. (pseudo-Ada: Function Index return Array (Positive range
> 1..Index_Count) of Discrete_Type)

Of course any type. The index type must implement index interface, which 
basically operations required to loop through the array.

>> 2. Index range type (or general index set type)
>> 3. Array element type
>> 4. Array set of elements type
> 
> What do you mean by "set of elements" type? Something like Pascal's Set?

Slice is a set of elements. For a ND array there are N-1 types of 
subsets unless you allow columns. Then it is more.

>>> (4) It seems ranges would have to become first-class types in order
>>> to satisfy the return-value of the Range attribute. (Though perhaps
>>> some compiler-magic like is done w/ Ada.Iterator_Interfaces and the
>>> for-loop might handle that...)
>>
>> Yes. And you need index operations defined on non-flattened indices and
>> sets of. Compare:
>>
>>      A (I, J)   -- Flatten
>>
>>      A ((I, J)) -- Elevated, same as
>>
>>       Point   := (I, J);
>>       Element := A (Point);
>>
> I *think* I get what you're saying here, but I'm not entirely sure I 
> do. (In essence you want to be able to have A(X,Y) be like a
> function-call with the first, and like a cursor with the second where X
> & Y are keys, and "element" is the element, no?)
> Care to elaborate?
Of course you need getter and setter. And you cannot deal with lists of 
arguments like in C. It must be reduced to:

    Get (Array, Index) return Element
    Set (Array, Index, Element)

where Index is just one object. The language magic must flatten and 
elevate tuples of arguments as necessary. And for slices it is:

    Get (Array, Index_Set) return Elements_Set
    Set (Array, Index_Set, Elements_Set)

E.g. for 1D, Index_Set is Index range, Elements_Set is array slice.

>>> (5) It is uncertain whether making these inheritable would be good:
>>> on the plus side you could define an abstract-type that held the READ
>>> and WRITE and other common attributes and have a hierarchy of
>>> "type-classes".
>>
>> It is an interesting question which was discussed in OO. E.g. if an
>> array of subtypes is a subtype (a subtype in general terms, rather than
>> Ada's sense). In some cases this is required, e.g. if we tried to bring
>> string types in order. Surely ASCII arrays must be compatible with
>> Latin-1 array etc.
> 
> Gag!
> 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.

So what? There is no logical reason for Latin-1's Put_Line not to work 
with ASCII. Note that in Ada string literal is compatible with all 
character arrays:

    Ada.Wide_Text_IO.Put_Line ("abcd");

and

    Ada.Text_IO.Put_Line ("abcd");

as simple as that.

>>> (6) The exposure of heretofore conceptual types. (e.g. Universal_Integer)
>>
>> Array requires positional access, just like discrete types have T'Pos
>> and T'Val. At leas for iteration, it does.
> 
> ??
> The concept of an array in Ada is that of a function:
>    The_Function (X,Y : Character) return Character; and
>    The_Array    (Character,Character) of Character;
> have very common interfaces for precisely this reason -- if anything
> we want to extend this to full completion.

Not really.

> eg given Y : Character := X('A', 'B'); what is X? An array, or a function?

Depends on the type of X. What we want is translation

    X('A','B') --> Get (X, ('A','B'))

Get is a primitive operation of X.

>>> (7) The exposure of the "type of a type".
>>
>> This is difficult to make consistent with inheritance and dynamic
>> dispatch. Dispatching tables tend to be global. With type types you need
>> tagged types come and go. Difficult.
> 
> Why would dispatching even be an issue?
> The compiler already knows what types what objects are; all this is
> saying is that there needs to be a type which indicates the type,

This is a whole different thing. Indicates /= is. The type with values 
indicating types already exists. It is Ada.Tags.Tag.

>>> (8) Would it be worth it for compiler-writers? Language maintainers?
>>> Language users? -- On the one hand being able to indicate explicitly
>>> that "definite type X" has *these* attributes while "Fixed-point type Y"
>>> has *those* attributes might be pretty nice... especially if we could
>>> make interfaces a bit more consistant. (e.g. allowing both
>>> Indefinite_Vector_Var'Length and Array_Var'Length.)
>>
>> Clearly an attribute is just a primitive operation. There cannot be any
>> discussion about it.
> 
> No, they are something different than a mere primitive operation.
> All discrete types have 'First, this doesn't mean that there's a
> First operation, per se, available to values of that type... but
> rather that  the thing "discrete types" has a function "First".

Attributes defined on types are operations with the type being a part of 
name, since we have no first class type objects, or operations defined 
on Ada.Tags.Tag. BTW, many such attributes must be object's operations, 
e.g. S'Image(X), should have been X'Image.

>>> (9) On the user-side I think it would be great to be able to have
>>> the  Ada.Containers.Vector Vector-type have a compatible interface to
>>> Array... we're halfway there with the Vector_Var'Iterate + For-loop anyway.
>>
>> Yes, having non-generic containers would be a huge relief.
> 
> Who said anything about non-generic containers?

With array interfaces you would need no that mess.

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