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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada Annoyances Date: Sun, 2 Jul 2017 19:04:54 -0500 Organization: JSA Research & Innovation Message-ID: References: <1ac5a44b-4423-443a-a7bb-2864d9abe78f@googlegroups.com> <3df6404a-588d-4e2d-a189-1d1e32ce9f5d@googlegroups.com> Injection-Date: Mon, 3 Jul 2017 00:04:54 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="19535"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:47263 Date: 2017-07-02T19:04:54-05:00 List-Id: (1) Untagged primitive operations can be overridden "late", that causes problems for anything that calls them indirectly. Perhaps it could have been made to work, but it was more work for a feature that some people thought was marginal; probably it would have been dropped rather than getting more complicated. (2) Iteration is defined in terms of an interface, so by definition it only works with tagged types. Perhaps we should have not tried to build on other language features and just made iteration magic all the way (it certainly would have been easier to use that way), but taggedness is a consequence of that. (3) Since prefixed notation does automatic dereferencing and referencing (that is, .all and 'Access), allowing it on all types caused levels of ambiguity (and potentially infinite regress). It was easier to just define it on tagged types, which didn't have those issues. Perhaps it could have been made to work, but it was more work for a feature that already had significant opposition; probably it would have been dropped rather than getting more complicated. (Sound like a broken record??) Note that for versions of Ada prior to Ada 2012, you have to use tagged types if you expect "=" to work right. Untagged record "=" does not compose in original Ada. We eventually decided to fix that, but the fix means that substantial existing code won't compile with Ada 2012 (most of it didn't do what the author intended anyway, so whether that is a bad thing is hard to say). And of course if you need controlled types, you have to use tagged types. If you want any type extension (regardless of whether any dispatching or inheritance is involved), you have to use tagged types. So you have to use tagged types in most circumstances in Ada 2012. And given that the extra cost is a word or two per object, the overhead is insignificant in most cases. (The cases where it matters, tiny non-private objects that are used in large quantities, are those for which the missing features aren't usable anyway.) The real problem here is keeping compatibility with the messed-up definitions of untagged types in Ada; the most sensible thing to do would be to make all types effectively tagged (Dmitry likes to tell everyone how it ought to work), but that would be incompatible in many overriding cases. It would make more sense for Ada'Succ. Randy. wrote in message news:3df6404a-588d-4e2d-a189-1d1e32ce9f5d@googlegroups.com... On Friday, June 30, 2017 at 11:02:48 AM UTC-4, Norman Worth wrote: > You should not use tagged types where they are not needed. It messes up > the code. In general, if you are not going to have derived types, the > base type should not be tagged. In some cases you do not have a choice; this is why I started this thread in the first place. If you want to define custom indexing, custom iteration or use the object.method() syntax, you must use tagged types, regardless of whether or not you really need tagged types. It seems odd to me that you must pay an unnecessary cost to use these features just because the language says so (perhaps there is a reason behind the decision, but I can't see why), even if that cost is small.