Attribute denoting a subprogram : no named parameter associations allowed

Attribute denoting a subprogram : no named parameter associations allowed

[Hibou57 (Yannick Duchêne)]

Hello once again,

ARM 4.1.4 use the word “ subprogram ” when talking about an attribute
may denote.
> 9 An attribute_reference denotes a value, an object, a subprogram, or
> some other kind of program entity.

ARM 6.4, which is about subprogram calls, says
> 7 A parameter_association is named or positional according to whether or
> not the formal_parameter_selector_name is specified. Any positional associations
> shall precede any named associations. Named associations are not allowed if
> the prefix in a subprogram call is an attribute_reference.

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.

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

[Randy Brukardt]

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

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

[Adam Beneschan]

On Oct 27, 2:00 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Hibou57 (Yannick Duchêne)" <yannick_duch...@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.

I'm not entirely convinced that this really changed.  In Ada 95, 4.1.4
(9) says, "An attribute_reference denotes a value, an object, a
subprogram, or some other kind of program entity."

In Ada 83, 4.1.4(3) says, "An attribute can be a basic operation
delivering a value; alternatively it can be a function, a type, or a
range."  Functions are one kind of subprogram, and in Ada 83 there
were no attributes that denoted procedures; the stream attributes
'Read, 'Write, 'Output, which do denote procedures, were added in Ada
95.  Of course, you could argue that "function" doesn't necessarily
mean an "Ada function", which is a subprogram, but could mean a
function in the mathematical sense.  But looking at RM83 12.3.6
(1)---"A formal subprogram is matched by an actual subprogram,
enumeration literal, or entry if both have the same parameter and
result type profile (see 6.6)"---tends to convince me that attribute
functions *were* considered subprograms, since they could be used as
actuals in a generic instantiation.  They also had parameter and
result type profiles, like Ada subprograms; RM83 6.6 discusses
profiles for subprograms and entries and doesn't make any special
mention of attribute functions.

So I think that attribute functions *were* considered to be
subprograms back in Ada 83.  They certainly weren't the same as other
subprograms, in many respects---but they still aren't.  I could be
missing something, but I can't think of a way in Ada 95/2005 that
attribute subprograms are any more or less "magical" than they were in
Ada 83, or more or less like other subprograms.  I think the main
difference here is that RM95, in general, tried to be more formal
about defining things than RM83, whose language was a bit fuzzy in
places; that may be why it's clearer that in Ada 95, an attribute
denotes a subprogram, while in Ada 83, it's sort of kind of implied.
Also, in RM95 Appendix K, the actual profiles are shown for the
attribute subprograms, while in RM83 Appendix A, they weren't.  But
they had to have profiles, even in Ada 83, in order to work with
generic instantiation and subprogram renaming.

None of this matters, in any case, except to pedants.

                              -- Adam

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

[Hibou57 (Yannick Duchêne)]

On 27 oct, 23:36, Adam Beneschan <a...@irvine.com> wrote:
> None of this matters, in any case, except to pedants.
>
>                               -- Adam

I'm aware this question in the context of attributes has something
anecdotal, but this is just I like to use named association as soon as
there is at least two parameters in a call. So it happens a moment I
asked to my self “ why isn't it possible with attributes ” ?

About the weight of this matter, this is anecdotal, that's true
(pedant is a lot said, think this is about named association, which
are useful).

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

[Randy Brukardt]

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

"Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> wrote in message 
news:5bc23b42-3a87-463b-b7c8-ab1b426c5191@d10g2000yqh.googlegroups.com...
> I'm aware this question in the context of attributes has something
> anecdotal, but this is just I like to use named association as soon as
> there is at least two parameters in a call. So it happens a moment I
> asked to my self � why isn't it possible with attributes � ?
>
> About the weight of this matter, this is anecdotal, that's true
> (pedant is a lot said, think this is about named association, which
> are useful).

The short answer is that Ada 83 didn't allow it (even if they were 
technically functions) because the parameters had no names (as Adam noted, 
there is no profiles for those functions published in the Ada 83 standard).

When it was proposed for Ada 95, I griped about the implementation cost (as 
noted in my original message). Some other implementers agreed with me. When 
the scope reduction was applied to the Ada 9x proposal (the original 
language was just too large for the time, no one would ever have implemented 
it), things that were just "nice to haves" were removed (even if they were 
technically sound). This was in that category, so out it went. Same thing 
happened to conditional expressions and many other useful ideas.

The reasoning hasn't changed, so I don't think we'll be revisiting that any 
time soon.

                                              Randy.