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

[Shark8 <onewingedshark@gmail.com>]

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.