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 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a0c:d1d9:: with SMTP id k25mr30699714qvh.233.1560911809734; Tue, 18 Jun 2019 19:36:49 -0700 (PDT) X-Received: by 2002:aca:da43:: with SMTP id r64mr1010538oig.0.1560911809185; Tue, 18 Jun 2019 19:36:49 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!m24no2078326qtm.0!news-out.google.com!33ni53qtt.0!nntp.google.com!m24no2078312qtm.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 18 Jun 2019 19:36:48 -0700 (PDT) In-Reply-To: <728c4668-8fa0-4a57-a502-2bf476fc3940@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=174.23.151.147; posting-account=tfeRYAoAAACibzLrD_Ytyp0eQjMq_Py9 NNTP-Posting-Host: 174.23.151.147 References: <728c4668-8fa0-4a57-a502-2bf476fc3940@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Latest suggestion for 202x From: Micah Waddoups Injection-Date: Wed, 19 Jun 2019 02:36:49 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:56678 Date: 2019-06-18T19:36:48-07:00 List-Id: On Sun, Jun 16, 2019, 15:41 'Lucretia' via comp.lang.ada=20 > On Sunday, 16 June 2019 00:59:41 UTC+1, Micah Waddoups wrote: >=20 > > I have a suggestion, and I am sorry I haven't searched thoroughly to se= e if someone has suggested this already, though I don't believe they have. = Unicode=20 >=20 > I have, search for it. >=20 > >and UTF are supported very well, however, the support is simply limited = to the=20 >=20 > No, Ada's support for Unicode is bad, very bad, and broken. There is an a= rticle about Ada's Unicode support by someone online, can't remember, think= s it was by Flyx. >=20 > Ada needs a full Unicode implementation and not one that layer after laye= r of abstration which makes it heavy as f***, sorry League, you're out! >=20 > All the existing string stuff needs to be redone with traits and moved in= to string encoding type stuff. >=20 > Luke. I agree, with consideration for true Unicode, however, as with Unifont, dir= ect support for at least the literal characters covers perhaps 80% or more = of practical use in embedded programming and small programs. In this the w= ork done seems to classify, map, and handle encoding/decoding each official= glyph/character very well. My intent is to acknowledge the conservative, carefully added support that = has been added already. As a programmer eager for advancement and practical= ly in love with the Ada language so far, I am in favor of being very conser= vative when adding to or removing anything. The problem implied by our dis= cussion is that as a high and low level general purpose programming languag= e, Ada is sometimes called upon to handle standards or expectations that ar= e very difficult to keep in the realm of Ada's standards, which are readabi= lity, maintainability, as complete precision possible abstracted over all t= arget platforms, and integrity. When full support for Unicode is someday a= dded, I hope it is not too late to be useful, but it needs to be right, and= simple enough to apply the wide range of applications or environments supp= orted and considered by the Ada standards. As is often the case, I think if someone's implementation of Unicode suppor= t is correct enough, but small as well, it might be added to a compiler lib= rary first. This would help some people and help those responsible for the= next official standard of Ada to vet the techniques of that implementation= for the most future prove way to accomplish it in the standard. =20 My only idea of something close to merging with the Unicode standard is to = add to existing Unicode support a type that is essentially a wide_wide_stri= ng for the lower three bytes, but requires all entities to be represented w= ith the full modifying and layout indicators in a particular order that can= be parsed however needed. If that isn't enough, then a tree like structur= e that groups entities by modifier and visual effects. Unicode is an idea = with the literal specifics being a mix of techniques, so to properly suppor= t it with literal code and only one technique, there needs to be an interna= l encoding that handles the specifics only one way. It is bound to consume = more memory than most would like, and if it is to have integrity, it should= not compromise accuracy and efficacy to avoid this. Even so, the bytes re= presenting the modifying or such might be squeezed or enumerated for the in= ternal representation and intelligently included or discarded on export to = normal wide_wide_string. Maybe, to accomplish this, each entity could be a = record with several wide_character elements and one wide_wide_character. No= enumerated or condensed representation of the letter, if it be, may work b= y itself, because this would ignore the expanding nature of Unicode and mig= ht someday cause a problem. As for Asian combined characters, if only the c= haracters are necessary to define an entity, then there is room for all of = them. This is my little unpolished idea. Ultimately, I feel many concerns about one, the other, or both of the paren= thesis and square brackets being preferable, but this is all too particular= . As the standard started with parenthesis and the syntax allows for littl= e change between arguments and array indexes, the flexibility of changing a= function to an array is a quality that abstracts the syntax from the imple= mentation. This is mostly a good thing. The real reason I am in favor of the square brackets is that it allows clar= ification of arrays, and possibly aggregates, when building contents withou= t requiring indexing, regardless of the number of components (whether 1 or = 10, same syntax). Example: type Some_Array is array (positive range <>) of integer; Items3 : Some_Array (1..3) :=3D [50, 60, 80]; Items1 : Some_Array (1..1) :=3D [50]; Items5 : Some_Array :=3D [50, 60, 80, 100, 112]; Items01 : Some_Array :=3D [50]; Items0 : Some_Array :=3D []; -- similar to an empty string "" type Some_Record is record item_one:integer; item_two:integer; end record; Items2 : Some_Record :=3D [40, 90]; So, basically improving syntax for readability when specifying content. I = see no _other_ situation where there is enough improvement to be worth the = quirks and change of switching out the parenthesis. Certainly not in index= ing, and I see no reason no remove the use of parenthesis in building conte= nts. Others may disagree with me, but I would limit the use of square brac= kets to filling actual values. Syntax like: (Template with extra1, extra2= ) should be possible with [Template with extra1, extra2]. In practical = use, there should be a style recommendation to avoid parenthesis when squar= e brackets will work and be more clear, but a style choice of alternating b= etween the parenthesis and the square brackets is unnecessarily confusing i= n regards to the exact meaning of either. Limiting the meaning of square b= rackets makes the syntax more clear and removes the verbosity of indexing s= ingle components or even no components, such as an empty array.