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: Thu, 10 Jan 2019 16:14:55 -0600 Organization: JSA Research & Innovation Message-ID: References: <2a6929c5-72fa-4d84-953a-44ea4597ab38@googlegroups.com> Injection-Date: Thu, 10 Jan 2019 22:14:56 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="8411"; 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:55259 Date: 2019-01-10T16:14:55-06:00 List-Id: "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). ... >> 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. 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. Note that historically, such redesigns tended to kill languages (Algol 68 followed Algol 60, but almost everything in the future was derived from Algol 60, especially the Wirth Algol W design, which eventually became Pascal, which was the major inspiration for Ada). >> Anyway, #1 has to be part of the contract of the generic. Doesn't make >> sense >> otherwise. And packaging all of the contracts into a single entity has >> been >> tried in many ways (that's the original reason for formal packages, the >> so-called signature package) -- and it's always too inflexible. Best to >> just >> have the individual requirements clearly stated in the profile of the >> generic. (I'd have said "interface", meaning the concept, not the >> feature, >> but that gets too confusing.) > > Sure. It is the same problem in both cases. The solution that would work > for generics is exactly the interfaces (universal) I am talking about. > Presently, it is only tagged contracts that are allowed (tagged type or > Ada interface). And they work perfectly. If we introduced externally > tagged contracts they would work out of the box just same. Ah, but we > would not need generics then... I don't quite see how that would work. ... >>> I do not understand why. Create an anonymous instance, clone the >>> hierarchy, constrain Element'Class to the concrete type T. Everything >>> must >>> be done by the compiler in one step as it does for array types. >> >> Well, separate array types are a mistake given that there are many >> implementations for a sequence. > > There is more than one type of sequences. Sounds like a tautology already. The place where interfaces (some more general feature than the one Ada has!) are useful is the case where you have to decouple the interface from representation. I find this a rare need that shows up mainly in the language-defined libraries (obviously YMMV). But it shows up there in a mammoth way. In particular, sequence and string interfaces (again, not like an existing Ada feature) are critical, because the representations vary so wildly. Ada 2020 has gone to great lengths to make arrays and containers work pretty much the same way, adding a rather complicated aggregate mechanism and adding parallelism to iterators. I start to wonder why (other than compatibility) we have built-in array types at all; just make a fixed container similar to vectors for what is now arrays. Whether such interfaces really gain being a general feature (I'm dubious) or something built-in (as in current Ada) doesn't change the need for them. There's no reason for an array or a vector to be different in any way at all -- if the compiler wants to build in support for one or more special cases is not relevant to the language design. In any case, I see the theroetical advantages of having some sort of interface mechanism, but I just don't see the uses in practice that make them a feature worth all of the implementation and definitional complication. ... >> There's no way it could be >> compatible enough, to do so would be to do great violence to that >> "advanced >> type system". Because most of the details of Ada types aren't advanced in >> any sense. :-) > > We have discussed that many times. I see no reason why it should be > incompatible. Except, maybe, for a few obscure cases with generics, nobody > really cares about. There is no more than a half-dozen people in the world > who know how these must work while they all disagree with each other... > (:-)) Having done this sort of thing for decades now, I have to respectfully disagree. There are many rather unusual corner cases in Ada having to do with interactions between visibility and resolution and overriding which make going much beyond the current model impossible. 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. The sort of model you are suggesting would lead directly to the same sort of issues. And the problem with "obscure" corner-cases that are incompatible is that they tend to keep people from upgrading even if the language design is better off with them. Because almost everyone has code that depends on some of those obscure corner cases. 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. Randy.