From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,CP1252 Path: g2news2.google.com!postnews.google.com!r24g2000prf.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Attribute denoting a subprogram : no named parameter associations allowed Date: Tue, 27 Oct 2009 15:36:11 -0700 (PDT) Organization: http://groups.google.com Message-ID: <7073f784-e47f-4eea-9738-8ecec7648798@r24g2000prf.googlegroups.com> References: <26d15919-f609-4878-8960-61bc87913cca@p23g2000vbl.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1256682971 9126 127.0.0.1 (27 Oct 2009 22:36:11 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 27 Oct 2009 22:36:11 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: r24g2000prf.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:8817 Date: 2009-10-27T15:36:11-07:00 List-Id: On Oct 27, 2:00=A0pm, "Randy Brukardt" wrote: > "Hibou57 (Yannick Duch=EAne)" wrote in message > news:26d15919-f609-4878-8960- > > > The important thing is the =93 Named associations are not allowed if th= e > > prefix in a subprogram call is an attribute_reference. =94, 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