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: Wed, 9 Jan 2019 17:38:50 -0600 Organization: JSA Research & Innovation Message-ID: References: <2a6929c5-72fa-4d84-953a-44ea4597ab38@googlegroups.com> Injection-Date: Wed, 9 Jan 2019 23:38:51 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="8387"; 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:55251 Date: 2019-01-09T17:38:50-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:q159mg$1q6k$1@gioia.aioe.org... > On 2019-01-09 00:26, Randy Brukardt wrote: > >> But that's the point: there aren't any significant tagged classes here, >> just >> generic classes, because there is only one instance of each class (use of >> formal packages can't change that). > > This is what I do not understand. Instance of a class is a type. Do you > mean the depth of the hierarch,y probably? Because the number of sibling > instances is usually large. But the siblings are incompatible with each other (different types, as you say). So there is no sharing that can be done between them other than that which comes directly from the generic unit itself. 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? ... >> No, I argue that given that there is no realistic alternative (other than >> to >> abandon strong static typing by deriving everything from a common type, >> then >> store Object'Class). > > It cannot be Object'Class because that includes limited types etc. There > are lots of constraints on the elements depending on the container, like > ordering, hashes. These constraints must be spelled in the language, not > silently assumed. A named interface is a language to spell such > constraints. #1. 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.) 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.) > The instances must be further constrained by the user from his side. Just > like we declare an array type, it does not mean that it can hold any > elements from the class of definite types. #2. > > It seems that you mix constraints #1 with #2. #1 has to be part of the contract of the generic; #2 clearly is not. Don't see any mixing there. >> If there was a way to have a universal container interface independent of >> the element type (and have that be useful), then the concept would be a >> lot >> more useful. But that isn't possible in any Ada-like language and retain >> static typing. > > 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. It would be better for them to be a container just like all of the others. I.e. I'd make it harder to declare an array rather making it easier to declare a container. :-) I discussed anonymous instances elsewhere; they do great damage to the Ada model that everything has a place and to readability. ... >> Which makes sense to me, since the primary benefit of inherited types is >> implementation reuse. Which interfaces don't allow. I'd surely support >> this >> position, but I think it is impractical to implement (as well as define >> properly rules for). > > Right, this is our main conceptual disagreement. You want to stick to > generics though they have proven not working. The only alternative is > inheritance (advanced type system). If only one percent of mental efforts > were invested into the type system instead, we could have a different and > IMO better Ada today. A different language, but it wouldn't be Ada. 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. :-) ... >>> I would gladly use Janus/Ada or ObjectAda if I could. I was a happy user >>> of the latter long ago. Unfortunately cross-platformity is a requirement >>> in these days. >> >> Understood. As you know, that costs $$$, and there aren't enough of those >> to >> go around. > > Sure, we need another crazy billionaire who would invest some bits of his > unearned wealth into Ada rather than in digging tunnels in seismically > active zones... (:-)) Agreed. :-) Randy.