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=BAYES_00,XPRIO autolearn=no autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada and Unicode Date: Mon, 4 Apr 2022 18:52:32 -0500 Organization: A noiseless patient Spider Message-ID: References: <607b5b20$0$27442$426a74cc@news.free.fr> <86mttuk5f0.fsf@stephe-leake.org> Injection-Date: Mon, 4 Apr 2022 23:52:33 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="ac27863b36cbdf6a5cef4d0e515606a9"; logging-data="15134"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/em04HVIR4pg/0tkVkMXwmana5ZKzEwhU=" Cancel-Lock: sha1:HqdT2Uf+eFEacbMkvPfZAThU1uI= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-RFC2646: Format=Flowed; Original X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-Priority: 3 X-MSMail-Priority: Normal Xref: reader02.eternal-september.org comp.lang.ada:63699 List-Id: "Thomas" wrote in message news:fantome.forums.tDeContes-5E3B70.20370903042022@news.free.fr... ... > 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. This certainly is a fine ivory tower solution, but it completely ignores two practicalities in the case of Ada: (1) You need to replace almost all of the existing Ada language defined packages to make this work. Things that are deeply embedded in both implementations and programs (like Ada.Exceptions and Ada.Text_IO) would have to change substantially. The result would essentially be a different language, since the resulting libraries would not work with most existing programs. They'd have to have different names (since if you used the same names, you change the failures from compile-time to runtime -- or even undetected -- which would be completely against the spirit of Ada), which means that one would have to essentially start over learning and using the resulting language. Calling it Ada would be rather silly, since it would be practically incompatible (and it would make sense to use this point to eliminate a lot of the cruft from the Ada design). (2) One needs to be able to read and write data given whatever encoding the project requires (that's often decided by outside forces, such as other hardware or software that the project needs to interoperate with). That means that completely hiding the encoding (or using a universal encoding) doesn't fully solve the problems faced by Ada programmers. At a minimum, you have to have a way to specify the encoding of files, streams, and hardware interfaces (this sort of thing is not provided by any common target OS, so it's not in any target API). That will greatly complicate the interface and implementation of the libraries. > ... of course, it would be very nice to have a more thicker language with > a garbage collector ... I doubt that you will ever see that in the Ada family, as analysis and therefore determinism is a very important property for the language. Ada has lots of mechanisms for managing storage without directly doing it yourself (by calling Unchecked_Deallocation), yet none of them use any garbage collection in a traditional sense. I could see more such mechanisms (an ownership option on the line of Rust could easily manage storage at the same time, since any object that could be orphaned could never be used again and thus should be reclaimed), but standard garbage collection is too non-deterministic for many of the uses Ada is put to. Randy.