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.98.192.209 with SMTP id g78mr656794pfk.24.1501815911051; Thu, 03 Aug 2017 20:05:11 -0700 (PDT) X-Received: by 10.36.137.194 with SMTP id s185mr24333itd.0.1501815910906; Thu, 03 Aug 2017 20:05:10 -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!u14no309148ita.0!news-out.google.com!196ni1424itl.0!nntp.google.com!u14no304730ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 3 Aug 2017 20:05:10 -0700 (PDT) In-Reply-To: <87h8y67trd.fsf@jacob-sparre.dk> 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: Subject: Re: Musing on defining attributes and the ability to define an "abstract type X"-interface. From: Shark8 Injection-Date: Fri, 04 Aug 2017 03:05:10 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:47584 Date: 2017-08-03T20:05:10-07:00 List-Id: On Thursday, July 20, 2017 at 2:12:08 PM UTC-6, Jacob Sparre Andersen wrote= : > Shark8 wrote: >=20 > > No, an array of ASCII is *NO* compatible with an array of Latin-1; the > > first is 7-bit data, the latter is 8-bit data. >=20 > Depends on whether you worry about encoding or just consider ASCII and > Latin-1 as character sets. If you're just thinking of character sets, > consider: >=20 > subtype Latin_1_String is Wide_Wide_String > with Dynamic_Predicate =3D> (for all C of Latin_1_String =3D> Charac= ter'Val (C) < 256); >=20 > subtype ASCII_String is Latin_1_String > with Dynamic_Predicate =3D> (for all C of ASCII_String =3D> Characte= r'Val (C) < 128); This has the implicit idea of a super-set [in this case Latin-1] which is f= ine, until you get into the representation territory. [Representation isn't= /quite/ the same thing as encoding.] To illustrate, a proper and strict ASCII string would be: Type ASCII_Character is Character range Character'First..Character'Pred= ( Character'Pos(128) ); Type ASCII_String is Array(Positive Range <>) of ASCII_Character with Component_Size =3D> 7, Packed; But this isn't *REALLY* about strings in and of itself, that's just where i= t becomes most obvious, it's rather about being able to: (a) turn the current implicit hierarchy into an explicit one, (b) in a manner that will allow user the usage, (c) especially in the area of uniformity, and (d) also permits the [re]definition of our current language type-classes/-kinds/-classifications. IOW, what I want to do is leverage the language's underlying concepts, maki= ng them explicit, and using *THAT* to unify/define what is already (in some= sense) required... like how universal_integer attributes require a bignum = package, but the language doesn't require its exposure.