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!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: class wide iterable (and indexable) Date: Mon, 14 Jan 2019 16:59:20 -0600 Organization: JSA Research & Innovation Message-ID: References: <2a6929c5-72fa-4d84-953a-44ea4597ab38@googlegroups.com> Injection-Date: Mon, 14 Jan 2019 22:59:21 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="25352"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-RFC2646: Format=Flowed; Response Xref: reader01.eternal-september.org comp.lang.ada:55275 Date: 2019-01-14T16:59:20-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:q19mh2$19lu$1@gioia.aioe.org... > On 2019-01-10 23:14, Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message >> news:q1715k$1fou$1@gioia.aioe.org... >>> On 2019-01-10 00:38, Randy Brukardt wrote: >> ... >>>> That makes any interfaces >>>> (again, Ada interface feature) involved useless, as they're necessarily >>>> different than any other such interfaces, which means there isn't >>>> anything >>>> that you can do with them. So why have them at all? >>> >>> You mean declaring an interface inside the generic? >> >> Yes, because that's the only possibility if the interface has to be >> parameterized by a type in some way (as a container interface has to be). >> And most objects end up being parameterized by a type, else they tend to >> be >> single purpose (and those types tend not to be like any other). > > No, that is the way parametric polymorphism = generics works. Ada > interfaces are dynamic polymorphism and must be used accordingly. E.g. by > using an explicit class of elements to be constrained later in the > instances. (For a hammer everything is a nail) Perhaps, but then you can't build anything really generic (like the containers or Direct_IO). Forcing everything into a class just for the sake of that just replaces one set of problems with a different set. >>>> Making the elements much more expensive (because of the need to manage >>>> an >>>> expensive tag) than they otherwise would be. There's a lot of pushback >>>> on >>>> even making language-defined units tagged, because of overhead >>>> concerns. >>>> (Don't buy that myself, but that's the mindset.) >>> >>> Yes, but this is another roadblock. Elements of containers should be >>> externally tagged by-value types. That would eliminate the overhead. >> >> That pushes the cost to other places (i.e. parameter passing instead of >> object declaration). I was including that model in my thinks (not >> necessarily in the thinking of others, of course). Tucker calls this the >> "bump under the carpet" problem. You can move the bump around, but you >> can't >> get rid of it. > > It is the same mechanism that is used for passing array bounds. And if > statically known (and all parents are abstract) the constraint can be > eliminated altogether, again like with arrays. You might be required to > adjust inherited operations, but again, this is no different from what you > do with shared generic bodies. Sure, but passing array bounds is pretty expensive. It's certainly more expensive than having a tag component, at least unless the number of objects >> number of calls. Again, you're just trading one set of costs for a different set. >> Ada probably can't use the separate tag model because of its insistence >> on >> supporting redispatching, even in inherited routines. I think you've >> convinced me that model was a mistake, but like many things in existing >> Ada, >> we're stuck with it short of a drastic (not completely compatible) >> redesign. > > There is no view conversions for such types, they are by-value. Thus no > way to even spell re-dispatch. Conversion to Parent'Class will create a > new object. Not necessarily, since we're also talking about untagged composite types. One hopes that we're not going to force strings or coordinates to be passed by copy (that would cause a lot of extra copying). Remember that program performance can be roughly determined by the amount of memory operations that it does. The more copying, the worse the performance. Only elementary types are roughly free to copy. ... ... >> For instance, we tried for a long time to work out rules that would allow >> hidden interfaces, but we just could not come up with anything that >> wasn't >> full of surprising cases or that totally destroyed privacy. That last >> thing >> anyone wants is their type extensions to do surprising things. We even >> restarted that a few years ago, but the solutions just get ridiculously >> complex. > > Interfaces should be allowed to be additive with the corresponding rules > to resolve conflicting implementations. There is an obvious contradiction > between invisibility and idempotence, e.g. if one entity is visible and > other is not. Let them add up and require conflict resolution in the > contexts where both become visible. What would that look like? Currently, you can only resolve conflicts with type names, and that certainly would not be enough in this case (the name of the interface being the same for every copy, as well as the type that has all of these interfaces). Numbering isn't going be reliable (the number of copies could differ for every view). So how could you deal with such conflicts? ... >> So, to do that sort of overhaul, you'd have to find a willingness to >> accept >> various incompatibities, and some group motivated enough to work out all >> of >> the details. Probably need the $$$ again. And it probably would be better >> off to start from scratch semantically in that case, because then you >> don't >> have to reproduce most of the warts. > > No, I don't believe that either. See how people keep on creating C. There > is a dozen of C-like languages redesigned from scratch, but the warts are > all there. The people doing that like a lot of about C already (why the mass hysteria on that, I don't know. Perhaps they don't even know that you can do better?). If I personally redesigned Ada, it would be a lot like the current Ada with some warts removed (strings and arrays in particular). I generally like the way Ada works, as I'm sure you know; I don't think a lot needs to be done to the type system. Clearly your vision is rather different. Randy.