Re: User-defined type attributes

[Eric Hughes <eric.eh9@gmail.com>]

On Mar 12, 3:23 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> Attributes in Ada aren't necessarily static, even type's attributes aren't.
> To me static functions is an independent, yet important issue.

Most attributes are completely static.  The ones that aren't (like
T'Callable, E'Caller) seem all to be of a kind that (1) statically
return a function (2) whose first parameter is the type of the object,
and then (3) apply it to that object.  Given that this is at least in
the spirit of a preelaborable attribute, there's the possibility of
treating these cases as syntactic shorthand: Obj'Attr for
Obj'Attr( Obj ), or alternately for Obj.Obj'Attr.  I did a brief scan
of ARM05/Annex-K just now, and this applies to all the cases I found
(which were all tasking or type attributes).

So I'll modify my idea to deal with historical syntax:
1) The definition of an attribute function has a static expression.
2) The syntax for invoking an attribute may imply a dynamic function
call.

Such implicit calls generate a syntax ambiguity between "attribute
procedure Op( X : T )" and "attribute procedure Op( X : T ; Y : T )"
when invoking with only positional parameters.  What would
Obj'Op( Obj ) mean?  I assume this can be adequately addressed.

> In my view attributes should be primitive operations. I would handle them
> similarly to prefix notation. I.e. X(Y,Z), Y.X(Z), Y'X(Z) considered
> equivalent.

The whole point of user attributes is to gain cleaner syntax for
referring to the environment of a type or object, that which is
available at pre-elaboration time, and supports generic programming
better.  Without such a syntax there are lots more formal parameters
that need to be forwarded around.

Just making attributes run-time functions eliminates a useful
distinction.  Functions on a type are part of the tradition algebraic
specification of a type.  Attributes on a type are part of the
language environment inside of which a type specification is
expressed.  These are very different.

> When applied to types, that should be treated just as a
> parameter of the type Tag.

That seems like the right way to treat the first parameter of an
implicit function call for an attribute on a type.

Eric