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 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!e25g2000prg.googlegroups.com!not-for-mail From: Eric Hughes Newsgroups: comp.lang.ada Subject: Re: User-defined type attributes Date: Thu, 13 Mar 2008 21:41:21 -0700 (PDT) Organization: http://groups.google.com Message-ID: <928f737d-955f-415b-93b1-ddbd24fbf81e@e25g2000prg.googlegroups.com> References: 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 1205469681 21177 127.0.0.1 (14 Mar 2008 04:41:21 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 14 Mar 2008 04:41:21 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: e25g2000prg.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:20365 Date: 2008-03-13T21:41:21-07:00 List-Id: On Mar 13, 7:46 pm, "Randy Brukardt" wrote: [re: consideration of user attributes] > Not seriously. It had been rejected for Ada 95, and in general, we didn't > want to rehash that old ground. Hmm. I do admit, unless you're specifically support heavy generic programming, it's not all that useful. I wrote: > > 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. [...] > That caused definitional and implementation problems. So we only allowed > tagged types. OK. That's a can of worms. I'm writing here, though, not to solve that problem but to provide motivation about why a solution is important. > That's OK, because only tagged types work "right" in Ada. [...] > > Thus, I think virtually all new composite types should be tagged in Ada > programs [...] I'm with you on the general idea. In my own code, most of my types are tagged. But the requirement to have them tagged in order to use the "." operator forces a trade-off: either (a) restrict generic parameters to tagged types or (b) avoid "." notation and be required to pull in whole packages rather than only single types. This doesn't match up with the separation of concerns (a.k.a. orthogonality) which is one of the hallmarks of Ada and one of the things I appreciate most about the language. The power of generic programming is to reinterpret the notation within a generic body through the parametric meaning of that notation. Today, for method invocations, that means "call through the virtual function table". That's certainly right for tagged types. It's too restrictive for other types. My goal is to envision a reasonable way of introducing into visibility all the affordances of a type with just the type name and not its whole package of definition. A hypothetical attribute such as T'Package isn't the right thing, since it would expand visibility (even if it were feasible to implement). What about tagging the function rather than the type? Imaginary example: function Op( X : T ) return X is tagged ; The sole purpose of the tag in this example is to mark a particular function signature as available through "." notation. Eric