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-Thread: 103376,c1fe4bc1dd51fc87 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!club-internet.fr!feedme-small.clubint.net!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: User-defined type attributes Date: Thu, 13 Mar 2008 20:46:37 -0500 Organization: Jacob's private Usenet server Message-ID: References: NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1205459234 32343 69.95.181.76 (14 Mar 2008 01:47:14 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 14 Mar 2008 01:47:14 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Xref: g2news1.google.com comp.lang.ada:20358 Date: 2008-03-13T20:46:37-05:00 List-Id: "Eric Hughes" wrote in message news:d9065e94-8586-4889-b5c7-a8ca9e8f2248@d21g2000prf.googlegroups.com... ... > First, a historical question: Was there a proposal for user attributes > that was considered for Ada 2005? Not seriously. It had been rejected for Ada 95, and in general, we didn't want to rehash that old ground. ... > 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. There are ambiguity problems because "any type" includes access types. Recall that '.' in Ada always includes an implicit dereference (and the prefixed notation also supports the reverse, an implicit 'Access). That is, A.B(C); could mean B(A, C); or B(A.all, C); or B(A'access, C); The latter should not be allowed for untagged types (they're not implicitly aliased). But, also it would be possible for it to mean B(A.all.all, C); and B(A.all.all.all, C); and so on forever. That caused definitional and implementation problems. So we only allowed tagged types. That's OK, because only tagged types work "right" in Ada. There are a number of bizarre behaviors (one involves "=" of types with components, and another with the "reemergence" of predefined operations inside of a generic) that had to be retained from Ada 83 for compatibility reasons. These language mistakes are corrected with tagged types. Thus, I think virtually all new composite types should be tagged in Ada programs; you'll be a lot happier for it. Keep in mind that the only runtime overhead for a tagged object in Ada is the space for the tag and the time to fill it in on initialization; calls are statically bound unless you use T'Class somewhere. I usually go further and say all new types should be controlled (so as to get user-defined finalization), but that does have a small runtime overhead if not used. Randy. > 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