Re: User-defined type attributes

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

On Thu, 13 Mar 2008 11:32:23 -0700 (PDT), Eric Hughes wrote:

> 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.

In which sense function is static? If understand what you wrote, it simply
means that the name "Callable" is static. Yes it is.

> 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.

Yes, as well as, Attr (Obj), which would be IMO a better way. I think
everybody is tired writing Integer'Image(X) rather than X'Image.

>  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).

Nevertheless the result is not static, thus it cannot be used, say, in a
declaration of a modular type. I consider this issue as fully independent.
We need static functions beyond attributes. Consider pattern matching:

   loop
      if Match (Text, Pattern ("*.ada")) then

there is no way to define Pattern in a way that would force the compiler to
translate "*.ada" at compile time.

> 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.

Why? The only thing you need is formal generic ADTs. Ada's generics lack
ADTs, which is the reason why you need to pass operations together with the
formal types. There exist formal built-in types like "private", "<>",
"digits <>" etc, but there is no user-defined ones. Add these and all
primitive operations will go with the actual type just per magic. It would
be IMO a natural step for anybody who wanted generics to evolve in an
Ada-way. (Not for me, as you know, I prefer generics removed from the
language.)

> 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.

I don't see why this distinction is important. Anyway it leaks, because you
certainly need constrained types in the types algebra. This brings
discriminants with it. Do you want to introduce attributes for the
discriminants of a subtype? Like X'Tag? which is of course merely a
discriminant. I think it would be an overkill.

Then what would you do with 'Pos, 'Succ, 'Adjacent etc attributes which
have nothing to do with types algebra? In my view this distinction just
does not hold since Ada 95, because that introduced user-defined classes.
In my view attributes in Ada 83 meant mere "magical things",
meta-subprograms which profiles cannot be spelt in the language. This has
changed, we can spell most of them now as proper primitive subprograms.
More elaborated class model of Ada will become less "magical things" will
remain.

I think now X'Y notation should be considered as pure syntax sugar, with no
semantics.

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