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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.200.37.101 with SMTP id 34mr3266616qtn.48.1502213306281; Tue, 08 Aug 2017 10:28:26 -0700 (PDT) X-Received: by 10.36.250.70 with SMTP id v67mr218997ith.2.1502213306238; Tue, 08 Aug 2017 10:28:26 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!paganini.bofh.team!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!w51no1254061qtc.0!news-out.google.com!1ni2204itx.0!nntp.google.com!u14no1316960ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 8 Aug 2017 10:28:25 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=76.113.92.25; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 76.113.92.25 References: <9617c73b-e23e-405b-8544-4d17e7e3ad61@googlegroups.com> <28512bf1-0c2c-400f-a24f-cc7e0eb8a02d@googlegroups.com> <87h8y67trd.fsf@jacob-sparre.dk> <36a1a83d-f3d7-4e3c-827d-addeadc28ccc@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <202c2f80-ad58-4fac-9fff-e064fed782a9@googlegroups.com> Subject: Re: Musing on defining attributes and the ability to define an "abstract type X"-interface. From: Shark8 Injection-Date: Tue, 08 Aug 2017 17:28:26 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:47650 Date: 2017-08-08T10:28:25-07:00 List-Id: On Monday, August 7, 2017 at 5:06:54 PM UTC-6, Randy Brukardt wrote: > "Shark8" wrote in message=20 > news:e8fcbf71-7432-4410-bae7-34943479bf81... > ... > >And this proposal is about adding the ability to extend to the whole=20 > >language > >without having to depend on (or be restricted to) tagged types. >=20 > Ada 9x originally allowed 'Class on all types. It eventually got dropped= =20 > because it was a lot of mechanism and Ada 9x looked like it might be too= =20 > complex for anyone to actually implement. (That was the infamous "scope= =20 > reduction"; a few thigns were snunk back in after that - specifically=20 > finalization and library-level renaming - but most of the stuff stayed ou= t.=20 > Some have reappeared in later versions of Ada.) >=20 > It's occassionally come up, but there hasn't been much interest in revivi= ng=20 > it in general, because it doesn't buy a lot. If you disagree, please come= up=20 > with examples of things are both important and hard to do with the curren= t=20 > language. I think you might be getting hung up on the word abstract and its connotati= on/connection to OOP -- and given your gut-reaction against "interface" I h= esitate to say "it's about interfaces". Dmitry was correct: On Sunday, August 6, 2017 at 1:04:40 AM UTC-6, Dmitry A. Kazakov wrote: >=20 > Surely Ada type system must be completely reworked in a > way that the current type system would be expressed in=20 > terms of the new system. That is what this proposal is about, not OOP or keyword "Interface"/"Abstra= ct", but bringing things together so that the whole current type-system can= be described uniformly in this new manner... and that is the key: UNIFORML= Y. Even you yourself have scratched the surface in recognizing that [[Wide_]Wi= de_]String ought to have a "base class" -- though your solution (ie Root_St= ring_Type) is a specific solution where if a general solution like this wer= e proffered we could do things like: have containers with the interface of = "array" [ie C'Length, C'First, etc]. On Monday, August 7, 2017 at 5:12:16 PM UTC-6, Randy Brukardt wrote: > "Shark8" wrote in message=20 > news:36a1a83d-f3d7-4e3c-827d-addeadc28ccc... > >!topic Adding an "Abstract Type" to enable simplification of the languag= e=20 > >definition. > >!reference Ada2012 RM??.??(??) > >!keywords abstraction, types, simplification > >!discussion >=20 > I doubt anyone wants to do a lot of work just to "simplify the language= =20 > definition". By years of experience, there is no such thing -- it will ju= st=20 > be a *different* language definition, with a different set of pitfalls.= =20 No, of course nobody *wants* to do it, but it needs to be done -- like main= tenance, when your project starts getting big and unwieldy (or you're broug= ht in to fix things) you refactor things where you can. Like using instance= s of a single Generic to ensure that things are the same and localize commo= n handling to a single place. Likewise, if the language is "built on" / "defined by" a uniform 'abstract = type' then common portions can be defined in a single place. -- A lot of pe= ople will jump to the conclusion that that's perfect for OOP inheritance at= this point, but they're wrong: inheritance is about specialization not, pe= r se, "code reuse". (Though admittedly you're going to have to have commona= lity in order to specialize.) Would this "move warts around"? Certainly. But this would also allow [some] warts to be addressed in common places, ra= ther than spread across the LRM -- it would also allow implementers to defi= ne Ada's type-system in a small core of "abstract types" which ought to be = easier to both implement and maintain than the current non-unified system. > Remember that the language is maintained almost exclusively by volunteers= -=20 > people are not signing up to make changes for the sake of changes. I'm signing up, and these *aren't* "changes for the sake of changes" but ra= ther an outgrowth of my experience in maintenance: if we can make things si= mpler and more uniform we can reduce the amount of pain we have maintaining= this. This is one of the big points that keeps new implementations from being fie= lded, Ada is a rather large language -- granted, you and I both realize tha= t this is not without cause, and that there is a necessary level of complex= ity (eg Duration & Date + their interactions) which is necessitated by the = desire to do things right. > My guess is that a proposal like this would go directly to the round file= =20 > (an AC, where it will be ignored forever). >=20 > If you want a proposal to be taken seriously, you have to explain the=20 > problem first, and then optionally give a solution. >=20 > As the request for Community Input says: >=20 > >For enhancement requests, it is very important to describe the programmi= ng > >problem and why the Ada 2012 solution is complex, expensive, or impossib= le. Again, I agree most of this proposal is indeed "moving things around" [and = "making things explicit"], but it is _NOT_ "changes for the sake of changes= " -- rather, they are changes for the sake of simplifying the language: in = definition, in implementation, and [ultimately] in usage.