From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!news.mixmin.net!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!cleanfeed2-b.proxad.net!nnrp6-1.free.fr!not-for-mail From: Thomas Newsgroups: comp.lang.ada Mail-Copies-To: nobody Subject: Re: Ada and Unicode References: <607b5b20$0$27442$426a74cc@news.free.fr> <86mttuk5f0.fsf@stephe-leake.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X) Date: Sun, 03 Apr 2022 20:37:10 +0200 Message-ID: Organization: Guest of ProXad - France NNTP-Posting-Date: 03 Apr 2022 20:37:10 CEST NNTP-Posting-Host: 91.175.52.121 X-Trace: 1649011030 news-2.free.fr 3679 91.175.52.121:10409 X-Complaints-To: abuse@proxad.net Xref: reader02.eternal-september.org comp.lang.ada:63690 List-Id: In article , "Randy Brukardt" wrote: > "Luke A. Guest" wrote in message > news:s5jute$1s08$1@gioia.aioe.org... > > > > > > On 19/04/2021 13:52, Dmitry A. Kazakov wrote: > > > > > It is practical solution. Ada type system cannot express differently > > represented/constrained string/array/vector subtypes. Ignoring Latin-1 and > > using String as if it were an array of octets is the best available > > solution. > > > > > > > They're different types and should be incompatible, because, well, they > > are. What does Ada have that allows for this that other languages doesn't? > > Oh yeah! Types! > > If they're incompatible, you need an automatic way to convert between > representations, since these are all views of the same thing (an abstract > string type). You really don't want 35 versions of Open each taking a > different string type. i need not 35 versions of Open. i need a version of Open with an Unicode string type (not Latin-1 - preferably UTF-8), which will use Ada.Strings.UTF_Encoding.Conversions as far as needed, regarding the underlying API. > > It's the fact that Ada can't do this that makes Unbounded_Strings unusable > (well, barely usable). knowing Ada, i find it acceptable. i don't say the same about Ada.Strings.UTF_Encoding.UTF_8_String. > Ada 202x fixes the literal problem at least, but we'd > have to completely abandon Unbounded_Strings and use a different library > design in order for for it to allow literals. And if you're going to do > that, you might as well do something about UTF-8 as well -- but now you're > going to need even more conversions. Yuck. as i said to Vadim Godunko, i need to fill a string type with an UTF-8 litteral. but i don't think this string type has to manage various conversions. from my point of view, each library has to accept 1 kind of string type (preferably UTF-8 everywhere), and then, this library has to make needed conversions regarding the underlying API. not the user. > > I think the only true solution here would be based on a proper abstract > Root_String type. But that wouldn't work in Ada, since it would be > incompatible with all of the existing code out there. Probably would have to > wait for a follow-on language. of course, it would be very nice to have a more thicker language with a garbage collector, only 1 String type which allows all what we need, etc. -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/