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.3.210 with SMTP id 201mr2333769pgd.145.1500568668419; Thu, 20 Jul 2017 09:37:48 -0700 (PDT) X-Received: by 10.36.46.15 with SMTP id i15mr4437ita.0.1500568668370; Thu, 20 Jul 2017 09:37:48 -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!t6no804609itb.0!news-out.google.com!196ni2806itl.0!nntp.google.com!t6no446125itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 20 Jul 2017 09:37:48 -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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <28512bf1-0c2c-400f-a24f-cc7e0eb8a02d@googlegroups.com> Subject: Re: Musing on defining attributes and the ability to define an "abstract type X"-interface. From: Shark8 Injection-Date: Thu, 20 Jul 2017 16:37:48 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:47470 Date: 2017-07-20T09:37:48-07:00 List-Id: On Thursday, July 20, 2017 at 1:52:14 AM UTC-6, Dmitry A. Kazakov wrote: > You need along with the array type: >=20 > 1. Index type >=20 > This is for 1D arrays. For ND arrays you need types in-between (tuples=20 > of indices) and sub-arrays. Making a specialized interface for 1D arrays seems, well... stupid, especia= lly when we're talking about such a change to the language so as to easily = open up the full generality. IOW, why have just "index type" for an array? At this point you're just using generics, albeit with a different name. We = need an array of indices of type, but not just any type, discrete-type. (ps= eudo-Ada: Function Index return Array (Positive range 1..Index_Count) of D= iscrete_Type) > 2. Index range type (or general index set type) > 3. Array element type > 4. Array set of elements type What do you mean by "set of elements" type? Something like Pascal's Set? > > (4) It seems ranges would have to become first-class types in order=20 > > to satisfy the return-value of the Range attribute. (Though perhaps > > some compiler-magic like is done w/ Ada.Iterator_Interfaces and the > > for-loop might handle that...) >=20 > Yes. And you need index operations defined on non-flattened indices and= =20 > sets of. Compare: >=20 > A (I, J) -- Flatten >=20 > A ((I, J)) -- Elevated, same as >=20 > Point :=3D (I, J); > Element :=3D A (Point); >=20 I *think* I get what you're saying here, but I'm not entirely sure I do. (I= n essence you want to be able to have A(X,Y) be like a function-call with t= he first, and like a cursor with the second where X & Y are keys, and "elem= ent" is the element, no?) Care to elaborate? > > (5) It is uncertain whether making these inheritable would be good:=20 > > on the plus side you could define an abstract-type that held the READ > > and WRITE and other common attributes and have a hierarchy of > > "type-classes". >=20 > It is an interesting question which was discussed in OO. E.g. if an=20 > array of subtypes is a subtype (a subtype in general terms, rather than= =20 > Ada's sense). In some cases this is required, e.g. if we tried to bring= =20 > string types in order. Surely ASCII arrays must be compatible with=20 > Latin-1 array etc. Gag! No, an array of ASCII is *NO* compatible with an array of Latin-1; the firs= t is 7-bit data, the latter is 8-bit data. >=20 > > (6) The exposure of heretofore conceptual types. (e.g. Universal_Intege= r) >=20 > Array requires positional access, just like discrete types have T'Pos=20 > and T'Val. At leas for iteration, it does. ?? The concept of an array in Ada is that of a function: The_Function (X,Y : Character) return Character; and The_Array (Character,Character) of Character; have very common interfaces for precisely this reason -- if anything we wan= t to extend this to full completion. eg given Y : Character :=3D X('A', 'B'); what is X? An array, or a function= ? >=20 > > (7) The exposure of the "type of a type". >=20 > This is difficult to make consistent with inheritance and dynamic=20 > dispatch. Dispatching tables tend to be global. With type types you need= =20 > tagged types come and go. Difficult. Why would dispatching even be an issue? The compiler already knows what types what objects are; all this is saying = is that there needs to be a type which indicates the type, a "type of a typ= e" would therefore be analogous-to/exposure-of the-thing-the-compiler-uses-= to-indicate-the-type... not "type kinds" or "type classes". (Type kinds/classes could be useful, but we're talking about a way to imple= ment a sort of type kind/class and it seems a bit awkward to first require = type kinds/classes to implement type kind/classes.) >=20 > > (8) Would it be worth it for compiler-writers? Language maintainers? > > Language users? -- On the one hand being able to indicate explicitly > > that "definite type X" has *these* attributes while "Fixed-point type Y= " > > has *those* attributes might be pretty nice... especially if we could > > make interfaces a bit more consistant. (e.g. allowing both > > Indefinite_Vector_Var'Length and Array_Var'Length.) >=20 > Clearly an attribute is just a primitive operation. There cannot be any= =20 > discussion about it. No, they are something different than a mere primitive operation. All discrete types have 'First, this doesn't mean that there's a First oper= ation, per se, available to values of that type... but rather that the thin= g "discrete types" has a function "First". >=20 > > (9) On the user-side I think it would be great to be able to have > > the Ada.Containers.Vector Vector-type have a compatible interface to > > Array... we're halfway there with the Vector_Var'Iterate + For-loop any= way. >=20 > Yes, having non-generic containers would be a huge relief. Who said anything about non-generic containers?