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

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

[Shark8]

Also, somewhat tangential to my post on user-defined attributes, if there were a way to define attributes could it perhaps be used to make an "abstract type" interface, allowing something like:

Abstract Type Array_Type is record
  -- Not predefined attributes.
  Function Index_Count return Positive;
  Function Index_Type( Index : Positive := 1 ) return (<>); -- As in generic parameters.

  -- Predefined Array Attributes.
  Function First     ( Index : Positive := 1 ) return Index_Type(Index)
   with Pre => Index <= Array_Type'Index_Count;
  Function Last      ( Index : Positive := 1 ) return Index_Type(Index)
   with Pre => Index <= Array_Type'Index_Count;
  Function Length    ( Index : Positive := 1 ) return Natural
   is ( Integer'Succ(Array_Type'Last(Index) - Array_Type'First(Index)) );
  Function Range     ( Index : Positive := 1 ) return Range -- Not in current Ada.
   is ( Array_Type'First(Index)..Array_Type'Last(Index) );

  -- Predefined Subtype Attributes.
  Function Alignment return Universal_Integer
   with Post => Alignment'Result >= 0;
  Function Definite return Boolean;
  
end record;

And, of course my example brings up points that would need to be addressed:
(1) How would we indicate that Array_Type has a non-null ordered set of indexers. [ Array_Type's Range attribute {1..X | x is the dimensionality of the array} ]
(2) How would we indicate the [sub]types of the indexes are not necessarily of the same [sub]type? [ex. Array(Integer,character) of X ]
(3) How would we indicate the "constrainedness" of a particular index? (Or does this matter?) [ex Array(Integer range <>,character) of X ]
(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...)
(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".
(6) The exposure of heretofore conceptual types. (e.g. Universal_Integer)
(7) The exposure of the "type of a type".
(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.)
(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.

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

[Dmitry A. Kazakov]

On 20/07/2017 02:06, Shark8 wrote:
> Also, somewhat tangential to my post on user-defined attributes, if
> there were a way to define attributes could it perhaps be used to make
> an "abstract type" interface, allowing something like:
> 
> Abstract Type Array_Type is record
>    -- Not predefined attributes.
>    Function Index_Count return Positive;
>    Function Index_Type( Index : Positive := 1 ) return (<>); -- As in generic parameters.
> 
>    -- Predefined Array Attributes.
>    Function First     ( Index : Positive := 1 ) return Index_Type(Index)
>     with Pre => Index <= Array_Type'Index_Count;
>    Function Last      ( Index : Positive := 1 ) return Index_Type(Index)
>     with Pre => Index <= Array_Type'Index_Count;
>    Function Length    ( Index : Positive := 1 ) return Natural
>     is ( Integer'Succ(Array_Type'Last(Index) - Array_Type'First(Index)) );
>    Function Range     ( Index : Positive := 1 ) return Range -- Not in current Ada.
>     is ( Array_Type'First(Index)..Array_Type'Last(Index) );
> 
>    -- Predefined Subtype Attributes.
>    Function Alignment return Universal_Integer
>     with Post => Alignment'Result >= 0;
>    Function Definite return Boolean;
>    
> end record;
> 
> And, of course my example brings up points that would need to be addressed:

> (1) How would we indicate that Array_Type has a non-null ordered set 
> of indexers. [ Array_Type's Range attribute {1..X | x is the 
> dimensionality of the array} ]
You need along with the array type:

1. Index type
2. Index range type (or general index set type)
3. Array element type
4. Array set of elements type

This is for 1D arrays. For ND arrays you need types in-between (tuples 
of indices) and sub-arrays.

> (2) How would we indicate the [sub]types of the indexes are not necessarily of the same [sub]type? [ex. Array(Integer,character) of X ]
> (3) How would we indicate the "constrainedness" of a particular index? (Or does this matter?) [ex Array(Integer range <>,character) of X ]

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

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

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

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

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

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

But you know the answer already, don't you? (:-))

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

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

[Shark8]

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?

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

[Dmitry A. Kazakov]

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

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

[Jacob Sparre Andersen]

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

Greetings,

Jacob
-- 
"War does not determine who is right - only who is left."
                                         -- Bertrand Russell

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

[Shark8]

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.

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

[Simon Wright]

Shark8 <onewingedshark@gmail.com> writes:

> 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

OK so far

>      with Component_Size => 7, Packed;

AAARGH

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

[Dmitry A. Kazakov]

On 2017-08-04 05:05, Shark8 wrote:

> This has the implicit idea of a super-set [in this case Latin-1]
> which  is fine, until you get into the representation territory.

Still fine if interface inheritance allowed. The real problem is 
sticking to the idea that inheritance = extension.

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

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

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:ae46a44e-ee1e-42f6-ae8d-a02ae012e31d@googlegroups.com...
...
>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.

I made a stab at this some years ago (see the discussion of AI12-0021-1); 
the idea was to define a Root_String_Type that all of the others are derived 
from. Some messing around is needed to get literals and conversions. Idea 
being that a routine taking a Root_String_Type'Class parameter could handle 
any text string, with any representation or storage management (i.e. 
unbounded or fixed), without any explicit code.

I have no idea if there is any interest in pursuing this approach, or some 
similar approach; I don't think we ever discussed it in a meeting. 
Internationalization is supposed to be further addressed in Ada 2020, so I 
would hope that we'd discuss it someday soon.

                      Randy.

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

[Dmitry A. Kazakov]

On 2017-08-05 02:17, Randy Brukardt wrote:
> "Shark8" <onewingedshark@gmail.com> wrote in message
> news:ae46a44e-ee1e-42f6-ae8d-a02ae012e31d@googlegroups.com...
> ...
>> 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.
> 
> I made a stab at this some years ago (see the discussion of AI12-0021-1);
> the idea was to define a Root_String_Type that all of the others are derived
> from. Some messing around is needed to get literals and conversions. Idea
> being that a routine taking a Root_String_Type'Class parameter could handle
> any text string, with any representation or storage management (i.e.
> unbounded or fixed), without any explicit code.

There are concepts underlying this one.

> I have no idea if there is any interest in pursuing this approach, or some
> similar approach;

Not in this form. Because it is still looks like a hack.

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

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

[Shark8]

On Friday, August 4, 2017 at 6:17:58 PM UTC-6, Randy Brukardt wrote:
> "Shark8" wrote in message 
> news:ae46a44e-ee1e-42f6-ae8d-a02ae012e31d...
> ...
> >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.
> 
> I made a stab at this some years ago (see the discussion of AI12-0021-1); 
> the idea was to define a Root_String_Type that all of the others are derived 
> from. Some messing around is needed to get literals and conversions. Idea 
> being that a routine taking a Root_String_Type'Class parameter could handle 
> any text string, with any representation or storage management (i.e. 
> unbounded or fixed), without any explicit code.
> 
> I have no idea if there is any interest in pursuing this approach, or some 
> similar approach; I don't think we ever discussed it in a meeting. 
> Internationalization is supposed to be further addressed in Ada 2020, so I 
> would hope that we'd discuss it someday soon.
> 
>                       Randy.


I remember reading about that on an older thread, and I did read the AI. But this isn't about STRING-types, not really.

This is about having an "abstract type", it's about getting at the underlying interface (general-sense, not OOP-sense) and being able to explicitly use the already extant conceptual abstract types like "Universal_Integer" or "array type".

Here's what I have typed up for the initial Ada-Comment I'll post:

============================

!topic Adding an “Abstract Type” to enable simplification of the language definition.
!reference Ada2012 RM??.??(??)
!from Edward Fish 17-08-05
!keywords abstraction, types, simplification
!discussion

	The Ada language is currently defined using conceptual types and classifications, as such there is a lot of text dedicated to explaining these concepts which are only used by implementors, and then only tangentially as a side-effect of implementing the language.

As an example, there is a hierarchy of type-classes which is used to show how types relate to each other 

Ada Types
	│						(* Indicates a numeric type.)
	├─ Composite Types
	│	├─ Array
	│	├─ Record
	│	├─ Protected
	│	└─ Task
	└─ Elementary Types
		├─ Access
		└─ Scalar
			├─ Discrete
			│	├─ Enumeration
			│	└─ Integer*
			│		├─ Signed*
			│		└─ Modular*
			└─ Real*
				├─ Float*
				└─ Fixed*
					├─ Decimal*
					└─ Ordinary*


	The type in the hierarchy labeled Integer is NOT Standard.Integer, but rather the LRM’s Universal_Integer and doesn’t actually exist in the language except as a concept upon which to build. Likewise, but less-so, are the Composite types: there is no Universal_Array, Universal_Record, Universal_Task, or Universal_Protected except as referred to by the LRM in the abstract (as “Array type”, “Record type”, etc) and, possibly, in the formal-parameter hierarchy for generics. 
	By extending these concepts into the language directly we can simplify the language by exposing these abstract types; furthermore, such work will help in the construction of static checkers (like SPARK) as well as translator implementations because the 
	Additionally, with an abstract type we could make things more uniform for users of the language — in particular, with the extension of FOR-LOOP constructs [and addition of Ada.Iterator_Interface] to handle containers, we now have Containers which are able to be used as if they were arrays, though this is only partially true: there are no Container’Length or Container’Last or Container’First attributes… and as such we have to alternate between X.Last and X’Last depending on whether what we’re handling is a container or an array.

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

[Dmitry A. Kazakov]

On 2017-08-05 18:51, Shark8 wrote:

> This is about having an "abstract type", it's about getting at the
> underlying interface (general-sense, not OOP-sense)
First, it is the same sense. Second, Ada has abstract types (ADT is Ada 85).

The point is having hierarchies of types = classes.

- Ada 85 had built-in classes.
- Ada 95 added classes of tagged types with representations built by - 
record extension.
- Ada 2005 added classes of siblings sharing null representation (Ada 
interfaces).

There is a whole world beyond these.

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

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

[Shark8]

On Saturday, August 5, 2017 at 11:18:44 AM UTC-6, Dmitry A. Kazakov wrote:
> On 2017-08-05 18:51, Shark8 wrote:
> 
> > This is about having an "abstract type", it's about getting at the
> > underlying interface (general-sense, not OOP-sense)
> First, it is the same sense.  Second, Ada has abstract types (ADT is Ada 85).

Why do you assert this?
It's demonstrably not the case that it's OOP because, as you point out, Ada 83 had the concepts w/o being an OOP language.

As to the second point, ADT is Abstract Data Type -- we're obviously *NOT* talking about data here so it doesn't apply... and even if it did, you *still* would have to illustrate how and ADT provides the sort of access/uniformity of interface being talked about.

> The point is having hierarchies of types = classes.
> 
> - Ada 85 had built-in classes.
> - Ada 95 added classes of tagged types with representations built by - 
> record extension.
> - Ada 2005 added classes of siblings sharing null representation (Ada 
> interfaces).

And this proposal is about adding the ability to extend to the whole language without having to depend on (or be restricted to) tagged types.

> 
> There is a whole world beyond these.

Even within the Ada language there's more here.

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

[Dmitry A. Kazakov]

On 2017-08-05 23:29, Shark8 wrote:
> On Saturday, August 5, 2017 at 11:18:44 AM UTC-6, Dmitry A. Kazakov wrote:
>> On 2017-08-05 18:51, Shark8 wrote:
>>
>>> This is about having an "abstract type", it's about getting at the
>>> underlying interface (general-sense, not OOP-sense)
>> First, it is the same sense.  Second, Ada has abstract types (ADT is Ada 85).
> 
> Why do you assert this?

To make terms straight. Abstract type is abstracting values. What you 
(and I) want is abstract classes.

> It's demonstrably not the case that it's OOP because, as you point 
> out, Ada 83 had the concepts w/o being an OOP language.

Ada 83 was object-based.

OOP is programming in terms of sets of types + having instances from all 
set (=> dynamic polymorphism). ADT is a user-defined singular type. OOP 
 > ADT

> As to the second point, ADT is Abstract Data Type -- we're obviously
> *NOT* talking about data here so it doesn't apply... and even if it did,
> you *still* would have to illustrate how and ADT provides the sort of
> access/uniformity of interface being talked about.

I didn't say abstract type would.

>> The point is having hierarchies of types = classes.
>>
>> - Ada 85 had built-in classes.
>> - Ada 95 added classes of tagged types with representations built by -
>> record extension.
>> - Ada 2005 added classes of siblings sharing null representation (Ada
>> interfaces).
> 
> And this proposal is about adding the ability to extend to the whole
> language without having to depend on (or be restricted to) tagged types.

You need tags in order to have class-wide instances and operations. 
Built-in classes, e.g. like in Ada 83 did not allowed this. Polymorphism 
induced by these classes was static and thus restricted to generics.

You don't need to always have a tag inside a type-specific object, that 
is true.

>> There is a whole world beyond these.
> 
> Even within the Ada language there's more here.

It reached its limits and falls apart due to lack of 
abstractness/generality/universality.

I am not arguing with you. Surely Ada type system must be completely 
reworked in a way that the current type system would be expressed in 
terms of the new system.

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

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

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:e8fcbf71-7432-4410-bae7-34943479bf81@googlegroups.com...
...
>And this proposal is about adding the ability to extend to the whole 
>language
>without having to depend on (or be restricted to) tagged types.

Ada 9x originally allowed 'Class on all types. It eventually got dropped 
because it was a lot of mechanism and Ada 9x looked like it might be too 
complex for anyone to actually implement. (That was the infamous "scope 
reduction"; a few thigns were snunk back in after that - specifically 
finalization and library-level renaming - but most of the stuff stayed out. 
Some have reappeared in later versions of Ada.)

It's occassionally come up, but there hasn't been much interest in reviving 
it in general, because it doesn't buy a lot. If you disagree, please come up 
with examples of things are both important and hard to do with the current 
language.

                                      Randy.

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

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:36a1a83d-f3d7-4e3c-827d-addeadc28ccc@googlegroups.com...
>!topic Adding an "Abstract Type" to enable simplification of the language 
>definition.
>!reference Ada2012 RM??.??(??)
>!from Edward Fish 17-08-05
>!keywords abstraction, types, simplification
>!discussion

I doubt anyone wants to do a lot of work just to "simplify the language 
definition". By years of experience, there is no such thing -- it will just 
be a *different* language definition, with a different set of pitfalls. 
Remember that the language is maintained almost exclusively by volunteers - 
people are not signing up to make changes for the sake of changes.

My guess is that a proposal like this would go directly to the round file 
(an AC, where it will be ignored forever).

If you want a proposal to be taken seriously, you have to explain the 
problem first, and then optionally give a solution.

As the request for Community Input says:

>For enhancement requests, it is very important to describe the programming
>problem and why the Ada 2012 solution is complex, expensive, or impossible.

                                  Randy.

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

[Dmitry A. Kazakov]

On 2017-08-08 01:12, Randy Brukardt wrote:
> "Shark8" <onewingedshark@gmail.com> wrote in message
> news:36a1a83d-f3d7-4e3c-827d-addeadc28ccc@googlegroups.com...
>> !topic Adding an "Abstract Type" to enable simplification of the language
>> definition.
>> !reference Ada2012 RM??.??(??)
>> !from Edward Fish 17-08-05
>> !keywords abstraction, types, simplification
>> !discussion
> 
> I doubt anyone wants to do a lot of work just to "simplify the language
> definition".

It is much more that just definitions. More general concepts do solve 
problems. You would argue against Maxwell's theory of electromagnetism too.

> By years of experience, there is no such thing -- it will just
> be a *different* language definition, with a different set of pitfalls.

If you don't care about fundamentals and language consistency it will.

> Remember that the language is maintained almost exclusively by volunteers -
> people are not signing up to make changes for the sake of changes.

Even more important to concentrate resources on real problems rather 
than piling up kludges upon kludges. It was possible for Ada 95, it 
should be possible now.

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

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

[Shark8]

On Monday, August 7, 2017 at 5:06:54 PM UTC-6, Randy Brukardt wrote:
> "Shark8" wrote in message 
> news:e8fcbf71-7432-4410-bae7-34943479bf81...
> ...
> >And this proposal is about adding the ability to extend to the whole 
> >language
> >without having to depend on (or be restricted to) tagged types.
> 
> Ada 9x originally allowed 'Class on all types. It eventually got dropped 
> because it was a lot of mechanism and Ada 9x looked like it might be too 
> complex for anyone to actually implement. (That was the infamous "scope 
> reduction"; a few thigns were snunk back in after that - specifically 
> finalization and library-level renaming - but most of the stuff stayed out. 
> Some have reappeared in later versions of Ada.)
> 
> It's occassionally come up, but there hasn't been much interest in reviving 
> it in general, because it doesn't buy a lot. If you disagree, please come up 
> with examples of things are both important and hard to do with the current 
> language.

I think you might be getting hung up on the word abstract and its connotation/connection to OOP -- and given your gut-reaction against "interface" I hesitate to say "it's about interfaces".

Dmitry was correct:
On Sunday, August 6, 2017 at 1:04:40 AM UTC-6, Dmitry A. Kazakov wrote:
> 
> Surely Ada type system must be completely reworked in a
> way that the current type system would be expressed in 
> terms of the new system.

That is what this proposal is about, not OOP or keyword "Interface"/"Abstract", but bringing things together so that the whole current type-system can be described uniformly in this new manner... and that is the key: UNIFORMLY.

Even you yourself have scratched the surface in recognizing that [[Wide_]Wide_]String ought to have a "base class" -- though your solution (ie Root_String_Type) is a specific solution where if a general solution like this were proffered we could do things like: have containers with the interface of "array" [ie C'Length, C'First, etc].

On Monday, August 7, 2017 at 5:12:16 PM UTC-6, Randy Brukardt wrote:
> "Shark8" wrote in message 
> news:36a1a83d-f3d7-4e3c-827d-addeadc28ccc...
> >!topic Adding an "Abstract Type" to enable simplification of the language 
> >definition.
> >!reference Ada2012 RM??.??(??)
> >!keywords abstraction, types, simplification
> >!discussion
> 
> I doubt anyone wants to do a lot of work just to "simplify the language 
> definition". By years of experience, there is no such thing -- it will just 
> be a *different* language definition, with a different set of pitfalls. 

No, of course nobody *wants* to do it, but it needs to be done -- like maintenance, when your project starts getting big and unwieldy (or you're brought in to fix things) you refactor things where you can. Like using instances of a single Generic to ensure that things are the same and localize common handling to a single place.

Likewise, if the language is "built on" / "defined by" a uniform 'abstract type' then common portions can be defined in a single place. -- A lot of people will jump to the conclusion that that's perfect for OOP inheritance at this point, but they're wrong: inheritance is about specialization not, per se, "code reuse". (Though admittedly you're going to have to have commonality in order to specialize.)

Would this "move warts around"? Certainly.
But this would also allow [some] warts to be addressed in common places, rather than spread across the LRM -- it would also allow implementers to define Ada's type-system in a small core of "abstract types" which ought to be easier to both implement and maintain than the current non-unified system.


> Remember that the language is maintained almost exclusively by volunteers - 
> people are not signing up to make changes for the sake of changes.

I'm signing up, and these *aren't* "changes for the sake of changes" but rather an outgrowth of my experience in maintenance: if we can make things simpler and more uniform we can reduce the amount of pain we have maintaining this.

This is one of the big points that keeps new implementations from being fielded, Ada is a rather large language -- granted, you and I both realize that this is not without cause, and that there is a necessary level of complexity (eg Duration & Date + their interactions) which is necessitated by the desire to do things right.

> My guess is that a proposal like this would go directly to the round file 
> (an AC, where it will be ignored forever).
> 
> If you want a proposal to be taken seriously, you have to explain the 
> problem first, and then optionally give a solution.
> 
> As the request for Community Input says:
> 
> >For enhancement requests, it is very important to describe the programming
> >problem and why the Ada 2012 solution is complex, expensive, or impossible.

Again, I agree most of this proposal is indeed "moving things around" [and "making things explicit"], but it is _NOT_ "changes for the sake of changes" -- rather, they are changes for the sake of simplifying the language: in definition, in implementation, and [ultimately] in usage.

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

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ombrm4$18q4$1@gioia.aioe.org...
...
>> Remember that the language is maintained almost exclusively by 
>> volunteers -
>> people are not signing up to make changes for the sake of changes.
>
> Even more important to concentrate resources on real problems rather than 
> piling up kludges upon kludges. It was possible for Ada 95, it should be 
> possible now.

Experience is that the volunteers start to disappear if one is not working 
on new, important features for the language. Changing the underpinnings --  
with its high risk of making incompatible changes -- is not likely to get 
much traction. UNLESS it is tied directly to the solution of some high 
priority problem.

My main point to the OP is to find that high priority problem, *then* 
explain how a language design change would help to fix it. In the original 
post, there was nothing about problems, and next to nothing about what sort 
of language design change was contemplated, just a bunch of fluff about 
making the language more consistent. News flash: no real language is very 
consistent. It can't be and stilll be efficiently implementable. Ada has the 
additional constraint of remaining compatible in the vast majority of cases. 
That makes it hard to make any wholesale changes.

                                               Randy.

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

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:202c2f80-ad58-4fac-9fff-e064fed782a9@googlegroups.com...
...
>That is what this proposal is about, not OOP or keyword 
>"Interface"/"Abstract",
>but bringing things together so that the whole current type-system can be
>described uniformly in this new manner... and that is the key: UNIFORMLY.

No one is going to take this on, or even allow it to be done. It would cause 
dozens (probably hundreds) of bugs in the Standard's wording, which would 
have to be fixed down the road. (Just look at the number of bugs that adding 
preconditions, a much smaller change, caused.)

See also my response to Dmitry.

It doesn't matter if something is *better* (whatever that means), it matters 
if it is compatible with the current definition, it matters if the costs to 
implement it (both in the wording of the language standard and in 
implementations) are cheap enough, and it matters whether the problems that 
it will solve are important.

The only way to avoid spending all of our very limited time on way-out ideas 
that may lead nowhere is to very strictly ask for problems that need 
solving. The string mess needs solving, and preferably without adding 
Wide_Wide_Open to every I/O unit. No one has any problems for integer types 
that I know of.

>Even you yourself have scratched the surface in recognizing that
>[[Wide_]Wide_]String ought to have a "base class" -- though
>your solution (ie Root_String_Type) is a specific solution where
>if a general solution like this were proffered we could do things
>like: have containers with the interface of "array" [ie C'Length, C'First, 
>etc].

It would be better if arrays had a container interface, IMHO. The whole idea 
of an array is a rather archaic one, and it would be best if they were 
simply forgotten about. Moreover, we're only talking about a single 
character difference (C.Length vs. C'Length).

I was trying to solve the only real problem with strings, which is dealing 
with string literals. Even if you made some sort of overall generalization, 
you'd still need a special case for strings because you have to deal with 
string literals.

So, I don't see it; in any case, you need to show the problems that are 
being solved. Lack of uniformity is not a problem, per-se; it would be 
completely impossible to make a language that was completely uniform. 
(Tucker used to explain this as "bump under the rug" issues: you can move 
the bump around, but there is no way to actually eliminate it.)

                                              Randy.

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

[Dmitry A. Kazakov]

On 2017-08-09 02:44, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:ombrm4$18q4$1@gioia.aioe.org...
> ...
>>> Remember that the language is maintained almost exclusively by
>>> volunteers -
>>> people are not signing up to make changes for the sake of changes.
>>
>> Even more important to concentrate resources on real problems rather than
>> piling up kludges upon kludges. It was possible for Ada 95, it should be
>> possible now.
> 
> Experience is that the volunteers start to disappear if one is not working
> on new, important features for the language.

Reworking falling apart type system is important even if people do not 
feel it so. They may need more than 3 language iterations before it 
changes...

> My main point to the OP is to find that high priority problem, *then*
> explain how a language design change would help to fix it.

Sure, except that language is a thing that you could not improve by 
small incremental changes. The smaller the increment the worse it goes. 
This method does not work.

> In the original
> post, there was nothing about problems, and next to nothing about what sort
> of language design change was contemplated, just a bunch of fluff about
> making the language more consistent.

The problems as seen from the developer's perspective are different. We 
see the language differently. Consistency and regularity is more 
important for us than minor features or performance. These features may 
solve some "real" problem, but the developer does not see it, if the 
feature comes out of the blue buried somewhere in the reference manual. 
There must be higher language logic behind to make feature a solution. 
This means knowing how to apply, knowing what are the effects and 
pitfalls to the design.

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

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

[G.B.]

On 08.08.17 19:28, Shark8 wrote:
> changes for the sake of simplifying the language: in definition, in implementation, and [ultimately] in usage.

Simplification is not normally a viable business model.

Artificially maintained complexity, a preferance for supporting
legacy to verified rewriting(*), persuasively addressing fear in
view of ever growing old code: these will help businesses that
support the management of aging software. Consider "S"QL as a model
of managing relational data... (as opposed to some clean, core SQL).
Never draining enterprise funds!

(*) GNAT handles several editions of ISO Ada and more. But it does
not translate to, say, plain Ada 95.  And why should it do that?
Customers would be free to use updated Ada with well working Ada 95
compilers.

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

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:omebk4$1115$1@gioia.aioe.org...
> On 2017-08-09 02:44, Randy Brukardt wrote:
...
>> Experience is that the volunteers start to disappear if one is not 
>> working
>> on new, important features for the language.
>
> Reworking falling apart type system is important even if people do not 
> feel it so. They may need more than 3 language iterations before it 
> changes...

I don't think most of us see anything wrong with the type system. And I 
suspect that anyone who does has a different answer than anyone else. 
Building consensus would be very difficult.

>> My main point to the OP is to find that high priority problem, *then*
>> explain how a language design change would help to fix it.
>
> Sure, except that language is a thing that you could not improve by small 
> incremental changes. The smaller the increment the worse it goes. This 
> method does not work.

I don't disagree, but that's why languages are periodically effectively 
replaced by newer languages.

I once heard that adding structured programming to Fortran was like adding 
wheels to a horse and calling it an automobile. (I wonder what that 
commenter would have said about adding OOP to Fortran???).

Ada most likely has reached the point where only incremental changes are 
possible (especially given that there is no budget for a big redesign). 
Compatibility concerns, and avoiding major impact on existing 
implementations, are both significant factors that don't exist in new 
language designs. You also have to deal with a large community with 
competing interests, so there is a significant political component to the 
work.

>> In the original
>> post, there was nothing about problems, and next to nothing about what 
>> sort
>> of language design change was contemplated, just a bunch of fluff about
>> making the language more consistent.
>
> The problems as seen from the developer's perspective are different. We 
> see the language differently. Consistency and regularity is more important 
> for us than minor features or performance. These features may solve some 
> "real" problem, but the developer does not see it, if the feature comes 
> out of the blue buried somewhere in the reference manual. There must be 
> higher language logic behind to make feature a solution. This means 
> knowing how to apply, knowing what are the effects and pitfalls to the 
> design.

You (you meaning developers in general here) do care a lot about 
performance; if Ada programs for Ada 2020 performed more like Python 
programs than C programs, there would be a major outcry.

I'll make an assertion here: only toy languages not meant for 
high-performance computing (and often not having many users) can be very 
regular and consistent.

Case in point: An Ada that required all parameters to be passed by copy 
would be more consistent than the one we have, but it would have significant 
performance implications for records and arrays. The net effect would be 
that a lot of parameters would have to be anonymous access parameters --  
IMHO the wrong thing to put into public interfaces.

In the other direction, an Ada that required all parameters to be passed by 
reference would have performance issues when passing values of elementary 
types that are normally kept in registers. They'd have to be stored to 
memory before passing, which would double the number of reads and writes 
necessary for elementary parameter passing. The effect wouldn't be as 
clear-cut, but clearly some other languages (like C) would have a clear 
advantage in this cost.

Complete consistency comes at a cost, and that cost is often too high.

                                            Randy.

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

[Dmitry A. Kazakov]

On 2017-08-10 01:22, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:omebk4$1115$1@gioia.aioe.org...
>> On 2017-08-09 02:44, Randy Brukardt wrote:
> ...
>>> Experience is that the volunteers start to disappear if one is not
>>> working on new, important features for the language.
>>
>> Reworking falling apart type system is important even if people do not
>> feel it so. They may need more than 3 language iterations before it
>> changes...
> 
> I don't think most of us see anything wrong with the type system. And I
> suspect that anyone who does has a different answer than anyone else.
> Building consensus would be very difficult.

It is not that sort of wrongness. There is nothing wrong with rational 
numbers. But you cannot build functional analysis without extending it 
to reals.

>>> My main point to the OP is to find that high priority problem, *then*
>>> explain how a language design change would help to fix it.
>>
>> Sure, except that language is a thing that you could not improve by small
>> incremental changes. The smaller the increment the worse it goes. This
>> method does not work.
> 
> I don't disagree, but that's why languages are periodically effectively
> replaced by newer languages.

Is it so? Should it be so? I don't see how major new languages are so 
much better. The reasons why new languages appear are not technical, 
IMO. I would like to see an example of a language being replaced.

>> The problems as seen from the developer's perspective are different. We
>> see the language differently. Consistency and regularity is more important
>> for us than minor features or performance. These features may solve some
>> "real" problem, but the developer does not see it, if the feature comes
>> out of the blue buried somewhere in the reference manual. There must be
>> higher language logic behind to make feature a solution. This means
>> knowing how to apply, knowing what are the effects and pitfalls to the
>> design.
> 
> You (you meaning developers in general here) do care a lot about
> performance; if Ada programs for Ada 2020 performed more like Python
> programs than C programs, there would be a major outcry.

I mean minor performance penalties, not something catastrophic.

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

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

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:omh0da$1an0$1@gioia.aioe.org...
> On 2017-08-10 01:22, Randy Brukardt wrote:
...
>> You (you meaning developers in general here) do care a lot about
>> performance; if Ada programs for Ada 2020 performed more like Python
>> programs than C programs, there would be a major outcry.
>
> I mean minor performance penalties, not something catastrophic.

A lot of the stuff you ask for would result in Ada performing a lot more 
like Python than C, simply because implementing it would require a more 
interpretive approach - more like finding the appropriate action in a state 
machine rather than just executing the generated code. (Some parts of Ada 
are already like that, especially type conversions and memberships involving 
class-wide types.) That's especially true when every type has the 
compatibility.

                                       Randy.