comp.lang.ada
 help / color / mirror / Atom feed
From: Adam Beneschan <adam@irvine.com>
Subject: Re: Attribute denoting a subprogram : no named parameter associations allowed
Date: Tue, 27 Oct 2009 15:36:11 -0700 (PDT)
Date: 2009-10-27T15:36:11-07:00	[thread overview]
Message-ID: <7073f784-e47f-4eea-9738-8ecec7648798@r24g2000prf.googlegroups.com> (raw)
In-Reply-To: hc7n14$6ik$1@munin.nbi.dk

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



  reply	other threads:[~2009-10-27 22:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-25  6:27 Attribute denoting a subprogram : no named parameter associations allowed Hibou57 (Yannick Duchêne)
2009-10-27 21:00 ` Randy Brukardt
2009-10-27 22:36   ` Adam Beneschan [this message]
2009-10-27 23:47     ` Hibou57 (Yannick Duchêne)
2009-10-28 19:03       ` Randy Brukardt
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox