Re: Seeking for papers about tagged types vs access to subprograms

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Wed, 08 May 2013 10:23:48 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> BTW, range should become a proper type. That is the problem of parallel
> type hierarchies. I.e. describing relationships of unrelated yet bound to
> each other types, like index, range, array, slice, element. There should  
> be some general mechanism to handle such clouds of types.

That would come as natural. Just to stay with the range case, this would  
allow to have range object (we only have the range attribute, which is an  
UFO in the overall Ada entities model), without being forced to  
de‑structure it (as with some `First` and `Last` argument to a  
sub‑program), which would come with added safety at some place. This would  
permit proper functions and operations on ranges. I also noted some Ada  
new‑comers sometime feel surprised there is no way to pass or declare a  
range object in Ada, … that's indeed surprising, as there is a range  
attribute.

Creating the glue between an array type and a range type is straight away  
actually with Ada, but a more general model could be type properties. This  
would allow to declare things in a more readable and reliable way:


     -- Fictitious example, not real Ada

     A : Array_Type;
     I : A'Index_Type; -- As an attribute of an object
     J : Array_Type.Index_Type; -- As a member of a type.


May be an idea for something similar with primitive operations:


     -- Fictitious example, not real Ada

     function Implicit_Indexing
        (A : Array_Type; -- An array type or an array interface
         I : A'Index_Type)
         return A'Element_Type;


That would bind things together, and provide a more general model tan  
per‑type adhoc tricks (would help, if you want types at library level).

But then, an example such as the above would present challenge with  
derived types.

> BTW, range should become a proper type. That is the problem of parallel
> type hierarchies. I.e. describing relationships of unrelated yet bound to
> each other types

Not everything is bound to each‑other, there is a dependency order. When  
not, this means this is a [co‑]recursive structure, and there is already  
incomplete declarations for this (the most natural I think).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University