Re: Proposal: Constructors, Assignment [LONG]

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

Randy Brukardt wrote:

> Dmitry A. Kazakov wrote in message ...
>>Randy Brukardt wrote:
>>> The basic idea is to somehow figure a value of Ada.Tags.Tag, then use
> it
>>> to control dispatching on a function that returns the correct kind of
>>> object. This requires a special call:
>>>
>>>       Obj : T'Class := Func (<args>) use Tag_Value;
>>
>>The question is, will dispatching without an object be useful in cases
> other
>>than construction?

Why this sort of syntax was chosen? I think more consequently in Ada's 
spirit would be sort of:

   Obj : T'Class (Tag_Value) := Func (<args>);

Isn't tag a natural constraint/discriminant of T'Class?

> Yes, I think so. Two other examples have come up:
>   -- Calling the parent operation (which Ada does not have any
> convinient syntax for - currently you have to name the parent
> explicitly, which is a source of bugs);

Yes it would be nice. However you will need something to get a parent's type 
tag from the type tag.

>   -- Handling "least common denominator" comparison.

BTW. Why not to allow tag comparisons >, >=, <, <=? I mean:

   function ">" (Left, Right : Tag) return Boolean;

A>B if B is a descendant of A, but not of A type.

> These aren't wildly compelling, admittedly.
> 
>> This proposal requires new syntax. Mine
>>
>>   Obj : T'Class (<args>);
>>
>>requires only new attributes.
> 
> Adding syntax to a modern compiler is cheap. Either its table driven or
> recursive descent; both are quite simple. OTOH, semantics still have to
> be implemented by hand. The concern about syntax comes from the cost of
> modifying other tools. If there is a way to avoid new syntax without
> changing the semantics much, then that is to be preferred. But if we're
> talking about implementing simple syntax and semantics compared to
> implementing complex semantics only, I'll take a simple syntax change
> any day. And your proposal comes under complex semantics, and would be
> very expensive to implement in Janus/Ada.
> 
> Take your "only attributes" claim. In Janus/Ada (and probably other
> compilers), attributes are completely manually implemented. Every
> attribute is a bundle of special case code. It's especially expensive
> for attributes which can be specified. For instance, stream attributes
> (which these resemble) have dedicated components in type records which
> hold the current definition. Type records are initialized in a large
> variety of places in the compiler, and all of these would need to be
> updated (Ada 2005 will help that somewhat, but of course the compiler is
> implemented in Ada 95). So your "only new attributes" proposal would
> take many times more work to implement. Indeed, it would be impossible
> to implement without a wholesale restructuring of the compiler.

You know it better, of course. However, in a long term perspective most of 
attributes have to become just dispatching operations. Should all types be 
tagged in the sense that T'Class exists and one can derive with overriding 
its operations, then implementing of attributes would be much more easier.

> Secondly, you are suggesting that somehow:
>      Obj : T'Class (<args>);
> is somehow the same as
>      Obj : T'Class (<discriminants>);
> 
> Essentially, you are saying that a discriminant constraint has the same
> semantics as a parameter list.

We could turn it another way: the semantics of the parameter list in a 
constraint is same as one of a discriminant constraint.

> But that clearly isn't true in the RM as
> written. The rules for these are defined in different places and are
> subtly different. Changing them to be the same would be very difficult
> without introducing dangerous incompatibilities. While that arguably
> might be better for new users, it could be a disaster for existing Ada
> users (and code). And it certainly would be a heck of a lot of work.
> 
>>Though it is another question, I think that there is a need to have
>>something like user-defined anonymous access types, with the operations
>>becoming primitive for the pointed type. But it is probably far more
>>difficult than just constructors.
> 
> Well, there is a proposal for "named anonymous access types" (AI-230).
> But the whole idea of a named anonymous type is an oxymoron, and that
> turns off a lot of people. And there are quite a few semantic problems
> with the proposal. So I wouldn't expect that proposal to be included in
> Ada 2005.

Sigh. This could be a real breakthrough for OO programming and also an 
excellent response to GC-obsessed folks.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de