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

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

On Thu, 2 May 2013 16:49:18 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1d73jn954z90t.ze60axadntyr$.dlg@40tude.net...
>> On Wed, 1 May 2013 20:09:46 -0500, Randy Brukardt wrote:
> ...
>>> Nitpick: "new" is not an operator, it is an *operation*, things whose
>>> behavior cannot be modified directly. Like membership, it would be hard to
>>> make "new" an operator because one of the arguments can be a type (rather
>>> than an object or value), and it's hard to see how that could be mapped to
>>> an Ada function. (Adding type parameters seems over the top.)
>>
>>   type Root_Access_Type is interface ...;
>>   function "new" return Root_Access_Type is abstract;
>>
>> If access types were "untagged" class, "new" would be a plain primitive
>> operation.
> 
> You're missing something here, and that's the information about the 
> designated type/object. If you have:
> 
>      Ptr := new Piece (Color => Black);
> 
> that information about the discriminant has to be transmitted somehow as it 
> can controls the size of the allocated object.

Yes, but my response was to your point about the object's type. You don't
need explicit types with primitive operations, provided, the result is
properly typed. In all cases where Ada 83 used [sub]type specification:

   T'Image (X)
   new T (X)
   T (X)

etc, this was because of lack of typing.

Regarding discriminants, this is not a problem, because the signature of
the predefined "new" would be generated by the compiler, which could
include necessary parameters as it does now.

BTW, for constructors and allocators, there could a [sub]type attribute
T'Constraints which would yield a null record type with the discriminants
of T. E.g. let

   type Foo (X : Integer; Y : Boolean) is record
       I : Integer
   end record;

then Foo'Constraints is

   type Foo'Constraints (X : Integer; Y : Boolean) is null record;

This type + a mechanism to flatten tuples would give the signature you
wanted for "new" without compiler magic.

> Similar thoughts apply to memberships like "obj in T'Class". One might be 
> able to write a function to implement that, but you'd have to pass tags to 
> do so, which would bear no resemblance to normal subprogram call (it would 
> be much more like the relationship of a storage pool to an allocator).

To me X in T and X in T'Class are syntax sugar for operations on tags:

   X in T <=> X'Tag = T'Tag
   X in T'Class <=> X'Tag <= T'Tag (tree order)

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