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.99.179.5 with SMTP id i5mr4377507pgf.208.1501951894904; Sat, 05 Aug 2017 09:51:34 -0700 (PDT) X-Received: by 10.36.104.205 with SMTP id v196mr189986itb.3.1501951894864; Sat, 05 Aug 2017 09:51:34 -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!news.glorb.com!u14no619190ita.0!news-out.google.com!196ni3099itl.0!nntp.google.com!u14no619184ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 5 Aug 2017 09:51:34 -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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <36a1a83d-f3d7-4e3c-827d-addeadc28ccc@googlegroups.com> Subject: Re: Musing on defining attributes and the ability to define an "abstract type X"-interface. From: Shark8 Injection-Date: Sat, 05 Aug 2017 16:51:34 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:47612 Date: 2017-08-05T09:51:34-07:00 List-Id: On Friday, August 4, 2017 at 6:17:58 PM UTC-6, Randy Brukardt wrote: > "Shark8" wrote in message=20 > news:ae46a44e-ee1e-42f6-ae8d-a02ae012e31d... > ... > >IOW, what I want to do is leverage the language's underlying concepts,= =20 > >making > >them explicit, and using *THAT* to unify/define what is already (in some= =20 > >sense) > >required... like how universal_integer attributes require a bignum packa= ge,=20 > >but > >the language doesn't require its exposure. >=20 > I made a stab at this some years ago (see the discussion of AI12-0021-1);= =20 > the idea was to define a Root_String_Type that all of the others are deri= ved=20 > from. Some messing around is needed to get literals and conversions. Idea= =20 > being that a routine taking a Root_String_Type'Class parameter could hand= le=20 > any text string, with any representation or storage management (i.e.=20 > unbounded or fixed), without any explicit code. >=20 > I have no idea if there is any interest in pursuing this approach, or som= e=20 > similar approach; I don't think we ever discussed it in a meeting.=20 > Internationalization is supposed to be further addressed in Ada 2020, so = I=20 > would hope that we'd discuss it someday soon. >=20 > Randy. I remember reading about that on an older thread, and I did read the AI. Bu= t this isn't about STRING-types, not really. This is about having an "abstract type", it's about getting at the underlyi= ng interface (general-sense, not OOP-sense) and being able to explicitly us= e the already extant conceptual abstract types like "Universal_Integer" or = "array type". Here's what I have typed up for the initial Ada-Comment I'll post: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D !topic Adding an =E2=80=9CAbstract Type=E2=80=9D to enable simplification o= f the language definition. !reference Ada2012 RM??.??(??) !from Edward Fish 17-08-05 !keywords abstraction, types, simplification !discussion The Ada language is currently defined using conceptual types and classific= ations, as such there is a lot of text dedicated to explaining these concep= ts which are only used by implementors, and then only tangentially as a sid= e-effect of implementing the language. As an example, there is a hierarchy of type-classes which is used to show h= ow types relate to each other=20 Ada Types =E2=94=82 (* Indicates a numeric type.) =E2=94=9C=E2=94=80 Composite Types =E2=94=82 =E2=94=9C=E2=94=80 Array =E2=94=82 =E2=94=9C=E2=94=80 Record =E2=94=82 =E2=94=9C=E2=94=80 Protected =E2=94=82 =E2=94=94=E2=94=80 Task =E2=94=94=E2=94=80 Elementary Types =E2=94=9C=E2=94=80 Access =E2=94=94=E2=94=80 Scalar =E2=94=9C=E2=94=80 Discrete =E2=94=82 =E2=94=9C=E2=94=80 Enumeration =E2=94=82 =E2=94=94=E2=94=80 Integer* =E2=94=82 =E2=94=9C=E2=94=80 Signed* =E2=94=82 =E2=94=94=E2=94=80 Modular* =E2=94=94=E2=94=80 Real* =E2=94=9C=E2=94=80 Float* =E2=94=94=E2=94=80 Fixed* =E2=94=9C=E2=94=80 Decimal* =E2=94=94=E2=94=80 Ordinary* The type in the hierarchy labeled Integer is NOT Standard.Integer, but rat= her the LRM=E2=80=99s Universal_Integer and doesn=E2=80=99t actually exist = in the language except as a concept upon which to build. Likewise, but less= -so, are the Composite types: there is no Universal_Array, Universal_Record= , Universal_Task, or Universal_Protected except as referred to by the LRM i= n the abstract (as =E2=80=9CArray type=E2=80=9D, =E2=80=9CRecord type=E2=80= =9D, etc) and, possibly, in the formal-parameter hierarchy for generics.=20 By extending these concepts into the language directly we can simplify the= language by exposing these abstract types; furthermore, such work will hel= p in the construction of static checkers (like SPARK) as well as translator= implementations because the=20 Additionally, with an abstract type we could make things more uniform for = users of the language =E2=80=94 in particular, with the extension of FOR-LO= OP constructs [and addition of Ada.Iterator_Interface] to handle containers= , we now have Containers which are able to be used as if they were arrays, = though this is only partially true: there are no Container=E2=80=99Length o= r Container=E2=80=99Last or Container=E2=80=99First attributes=E2=80=A6 and= as such we have to alternate between X.Last and X=E2=80=99Last depending o= n whether what we=E2=80=99re handling is a container or an array.