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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,b02f5fed4171d18c X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news4.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!195.238.0.231.MISMATCH!news.skynet.be!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Attribute denoting a subprogram : no named parameter associations allowed Date: Tue, 27 Oct 2009 16:00:19 -0500 Organization: Jacob Sparre Andersen Message-ID: References: <26d15919-f609-4878-8960-61bc87913cca@p23g2000vbl.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1256677220 6740 69.95.181.76 (27 Oct 2009 21:00:20 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 27 Oct 2009 21:00:20 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Xref: g2news2.google.com comp.lang.ada:8811 Date: 2009-10-27T16:00:19-05:00 List-Id: "Hibou57 (Yannick Duch�ne)" 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.