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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c1fe4bc1dd51fc87,start X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!d21g2000prf.googlegroups.com!not-for-mail From: Eric Hughes Newsgroups: comp.lang.ada Subject: User-defined type attributes Date: Wed, 12 Mar 2008 11:58:29 -0700 (PDT) Organization: http://groups.google.com Message-ID: NNTP-Posting-Host: 166.70.57.218 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1205348310 3717 127.0.0.1 (12 Mar 2008 18:58:30 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 12 Mar 2008 18:58:30 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: d21g2000prf.googlegroups.com; posting-host=166.70.57.218; posting-account=5RIiTwoAAACt_Eu87gmPAJMoMTeMz-rn User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:20324 Date: 2008-03-12T11:58:29-07:00 List-Id: In light of the recent discussion of formal package parameters, I have been wondering about user-defined type attributes. They don't currently exist in any version of Ada. First, a historical question: Was there a proposal for user attributes that was considered for Ada 2005? My interest in them is akin to my interest in formal package parameters. The prefixed views for functions and procedures (dot- notation) of Ada 2005 are directly analogous to what would be required for attribute syntax. This notation hints at the possibility of a kind of visibility related to formal type parameters, one which would make ordinary subprograms and attribute functions visible without making the entire definition package visible. The idea is that a formal type parameter create a visibility related only to that type itself. In order to make this really useful, attribute functions would be needed to forestall the use of an entire package, rather than only a single type. If this seems abstruse, just consider the character traits that the C+ + standard library uses. And a related historical question: Why does the prefixed view of a subprogram only apply to tagged types? It seems like a syntax eminently suited for any subprogram. An attribute function must evaluate at compile-time, or perhaps more subtly, prior to elaboration time. Much of the requisite apparatus is already present with static expressions and preelaborable packages. The standard would require an additional definition of the ability to pre-elaborate a function body. While such a body might be restricted to returning a single static expression, that seem a bit restrictive. My overall motivation (as before) is to enable better, more flexible library support. Library support gates usability and enables cost- justifiable selection of Ada in a greater number of application domains. These kinds of features are not so critical for a single team writing their own software, but rather come into their own when writing libraries for other people to use in not-yet-anticipated ways. Eric