Re: Attribute denoting a subprogram : no named parameter associations allowed

["Randy Brukardt" <randy@rrsoftware.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

"Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> wrote in message 
news:26d15919-f609-4878-8960-
> The important thing is the � Named associations are not allowed if the
> prefix in a subprogram call is an attribute_reference. �, and indeed,
> the compiler don't want it.
>
> But why this restriction ? What is the rational for this restriction ?
>
> I do not see a reason why this may be a bad practice to use named
> parameter associations when the subprogram is denoted by an attribute.

Most attributes that represent subprograms don't have names for their 
parameters. That's a carry over from Ada 83, where attributes were magic 
things, not subprograms.

The main reason for the restriction is that redesigning Ada 83 compilers to 
allow calls of attributes with parameters out of order and the like would 
have required major surgery. For instance, in Janus/Ada, attributes are 
evaluated with their own separate code; nothing whatsoever is shared with 
calls. That's about 4000 lines of compiler code, all of which would have to 
totally written to make these first-class calls. And then the generated code 
would be much worse, as well.

The point is that attributes are built-in things that the compiler is 
expected to know about and generate the best possible code. Trying to 
support very general syntax and semantics with them would be detremental to 
the goal.

This is the same reason why we don't allow user-defined attributes. (The 
whole reason that Ada 95 changed these things to be officially subprograms 
was as part of a later dropped proposal to allow user-defined attributes. 
Personally, I don't think they every should have been changed from their Ada 
83 definition.)

                                                           Randy.