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!h11g2000prf.googlegroups.com!not-for-mail From: Eric Hughes Newsgroups: comp.lang.ada Subject: Re: User-defined type attributes Date: Sun, 16 Mar 2008 21:38:37 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <928f737d-955f-415b-93b1-ddbd24fbf81e@e25g2000prg.googlegroups.com> 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 1205728717 7950 127.0.0.1 (17 Mar 2008 04:38:37 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 17 Mar 2008 04:38:37 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: h11g2000prf.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:20442 Date: 2008-03-16T21:38:37-07:00 List-Id: On Mar 14, 9:20 pm, "Randy Brukardt" wrote: > Indeed, that is a frequent gripe that we (the ARG) have, and > something we try to avoid introducing more of. But I doubt that it can > really be fixed, simply because of compatibility. We can't change the > semantics of existing programs in ways that would break much of the existing > Ada code. Well, I don't think any of the ideas I've had recently about dot- notation are in the realm of changing pre-existing semantics. Instead, I'm concerned with keeping existing syntax patterns, enlarging the domain of applicability of that syntax, and creating new semantics that match existing practice. While that becomes more difficult as time goes forward, I think Ada's been pretty good about making conservative choices that attenuate the consequences of otherwise-rash decisions. > Thus you get things like tagged types which simply work better than other > kinds of types. That was introduced in Ada 95, and we have been happy to > continue it going forward. Tagged types do work better, sure. But they're not a panacea, either. It would a mistake to address other difficulties with types by shoehorning "solutions" to them into tags. And in the last couple of days I've realized the problems with untagged types as formal parameters is much greater than the absence of dot-notation. So here's a brief example. I'm writing a smart accessor package set right now. As something of an exercise, I'm doing this as generically as possible. So I'm looking to write code that can use both intrusive (part of the managed object) and accretive (separate from the managed object) allocation strategies for reference counts. And I want to do it without making the accessor types tagged. Since an intrusive accessor is simple a wrapped-up access object, adding a tag would double the machine size of an object. I consider this a poor result for a system-level library. My first foray at solving this was to use a formal type parameter for the implementation of the accessor. The intrusive implementation would contain just an access object; the accretive one would have that plus an access to a reference count. Pretty simple, so I thought. But without using a tagged type in the formal parameter definition, there's no visibility either for record components or for implicit visibility of operators on that type. Thus I couldn't get at components either directly or indirectly. I discarded that approach. It's a shame really, because it would otherwise be a natural representation of variety of in possible implementations. I'm still looking at other ways of approaching the problem. I'm beginning to suspect that doing this may be impossible, but I don't have an argument yet. Eric