From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.5-pre1 X-Received: by 2002:a05:620a:19:: with SMTP id j25mr4776513qki.299.1610126636578; Fri, 08 Jan 2021 09:23:56 -0800 (PST) X-Received: by 2002:a25:4148:: with SMTP id o69mr6940203yba.462.1610126636371; Fri, 08 Jan 2021 09:23:56 -0800 (PST) Path: eternal-september.org!reader02.eternal-september.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 8 Jan 2021 09:23:55 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=146.5.2.231; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 146.5.2.231 References: <1cc09f04-98f2-4ef3-ac84-9a9ca5aa3fd5n@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <37ada5ff-eee7-4082-ad20-3bd65b5a2778n@googlegroups.com> Subject: Re: Lower bounds of Strings From: Shark8 Injection-Date: Fri, 08 Jan 2021 17:23:56 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:61066 List-Id: On Thursday, January 7, 2021 at 3:03:54 PM UTC-7, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:rt6ltg$922$...=20 > ... > > No, one should have interfaces for such operations as well. > You're again losing sight of the ultimate goal here, which is to have a= =20 > conventionally compiled language that works close to the metal for high= =20 > performance. (And is compatible with embedded systems, runable from ROM,= =20 > etc.)=20 >=20 > Interfaces of any kind are completely counter to that goal, *especially* = in=20 > the case of arrays/vector containers. Why? An interface, in abstract, says very little about the implementation; it's = essentially equivalent to the "set of operations" side of the working-defin= ition of a Type: "A set of possible values and a set of operations on those= values." =E2=80=94 And aren't arrays commonly used in high-performance, "c= lose to the metal" computing all the time? It's also easy to imagine a wizard/database system which selects the proper= structure/set-of-structures for you given the constraints requested; in ps= udeo-SQL: Select from Structures where Look_up.Maximum <=3D Linear and Deletion.Avera= ge <=3D Linearithmic; Combining these two: you could, with an abstract interface, have a system t= hat chose an underlying/implementation structure given the requisite proper= ties, of which the interface could be a part. Similar to Ada's Generic para= meter "Type X is private" indicating any type which has assignment. > Any sort of multiple inheritance (not to mention multiple dispatch) requi= res=20 > searching a lookup table for the appropriate interface. Ah. It appears you're confusing the Ada concept underlying keyword INTERFACE wi= th the general/abstract notion. It appears to me that Dmitry is referring to the latter, not the Ada-constr= uct of INTERFACE, which requires a tagged type. I think what he's getting at is something that I considered/proposed here o= n C.L.A some years ago, adding the concept of an "ABSTRACT INTERFACE" to Ad= a. (IIRC, the proposal I had in mind was to be able to model the notional m= eta type-hierarchy; eg: Number =E2=8A=83 Universal_Integer =E2=8A=83 System= .Integer.) > If you aren't using the interface as such (that is, with some form of=20 > dispatching), then it is simply a complication with no semantic meaning.= =20 > There's no problem thinking about concepts as some sort of logical=20 > interface, but it is a distinction without meaning in that case. (By that= =20 > logic, Ada 202x has interfaces for Image, indexing, dereferencing, litera= ls,=20 > and streaming that can be applied to any tagged type.)=20 I don't think he is talking about dispatching. I also don't think that we need to *have* dispatching to have classes-of-ty= pes; the generic formal parameters exemplify that. > So either you are talking about a complication without value, or an=20 > extremely expensive implementation that doesn't meet the goals for a=20 > language like Ada. What's the point?=20 In the matter of the "ABSTRACT INTERFACE" idea, we could define things in s= uch a way at the language level that: (1) we could specify the notional types (eg Universal_Float, Universal_Fix= ed, etc) in this system, providing the interface of that type for the usage= of the language; (2) the specification of these notional-types would allow for less verbiag= e in the standard, and possibly allow proving on the classes they encompass= . I think it would be interesting to also have a sort of "ABSTRACT TYPE" that= could allow an Ada compiler/wizard-system (as mentioned above) fill in the= gap with some appropriately matching type; this would be good for the usag= e of prototyping, and probably also optimization, to have a way to say "I n= eed something that I can insert elements into, delete them, and index into,= but will never exceed 2**8 items." -- though this might be a bit too much = for some people/applications, especially those in fields where you commonly= specify bit-patterns and the like (there are times for those, but unless y= ou're doing the low-level stuff, you probably should let the compiler work = things out). =20 > BTW, you have yet to show me any useful example that you can't reasonably= do=20 > with a bounded vector (assuming that vector supports any discrete index= =20 > type). For almost any possible language feature, there's always some exam= ple=20 > where it works better than the alternative using the basic features of th= e=20 > language. But that's not the question, the question is whether it is wort= h=20 > it in terms of language complexity, opportunity cost (time spent=20 > implementing feature X is time not spent on features A, B, and C), and=20 > usability (too many special case features make it harder to learn and use= a=20 > language).=20 True, but making an appropriately abstract/general feature can allow you to= subsume/replace older features, defining them in terms of the new feature. If the ARG were more open to the idea of removing language features, we cou= ld be a bit more aggressive here; but that would mean breaking backwards-co= mpatibility, which is rather unpopular. > Slices fall on the wrong side of this boundary for me; the nonsense requi= red=20 > to implement them seems reasonable at first but rapidly disappears as of = the=20 > many other things that cannot be done in their presense. Can you give some examples here? > And they're mainly useful for strings, which are not arrays to begin with= . The proliferation of strings in Ada is lamentable; I would love to be able = to have a set of generics so you could instantiate with [[Wide_]Wide_]Chara= cter and get the current-Ada hierarchy. > > You cannot do that with a single type and single dispatch. > Exactly my point. The implementation of multiple inheritance and multiple= =20 > dispatch is simply too expensive for a language like Ada, and that's=20 > especially true in the case of basic building blocks like arrays/vectors. Some of the MI/MD motivation seems to be unnecessarily complicated, in addi= tion to the inherent complications. Though I do like the PRINT: PRINTER x IMAGE example, where you have the cla= ss of images and the class of printers for the parameters of Print, and the= re are good reasons for choosing to resolve first the printer or the image.