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 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)

> 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?


> > (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?

> > (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.

> 
> > (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.

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

> 
> > (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, a "type of a type" would therefore be analogous-to/exposure-of the-thing-the-compiler-uses-to-indicate-the-type... not "type kinds" or "type classes".

(Type kinds/classes could be useful, but we're talking about a way to implement a sort of type kind/class and it seems a bit awkward to first require type kinds/classes to implement type kind/classes.)

> 
> > (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".

> 
> > (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?