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-65-14.ec2.internal X-Spam-Level: * X-Spam-Status: No, score=1.1 required=3.0 tests=AC_FROM_MANY_DOTS,BAYES_00, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 Path: eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!cleanfeed2-b.proxad.net!nnrp1-2.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: Fri, 31 Mar 2023 05:06:22 +0200 Message-ID: <64264e2f$0$25952$426a74cc@news.free.fr> Organization: Guest of ProXad - France NNTP-Posting-Date: 31 Mar 2023 05:06:23 CEST NNTP-Posting-Host: 91.175.52.121 X-Trace: 1680231983 news-2.free.fr 25952 91.175.52.121:3517 X-Complaints-To: abuse@proxad.net Xref: feeder.eternal-september.org comp.lang.ada:65029 List-Id: In article , "Randy Brukardt" wrote: > "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, I like to think from an ivory tower, and then look at the reality to see what's possible to do or not. :-) > 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. - in Ada, of course we can't delete what's existing, and there are many packages which are already in 3 versions (S/WS/WWS). imho, it would be consistent to make a 4th version of them for a new UTF_8_String type. - in a new language close to Ada, it would not necessarily be a good idea to remove some of them, depending on industrial needs, to keep them with us. > 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. i think i don't understand. > (and it would make sense to use this point to > eliminate a lot of the cruft from the Ada design). could you give an example of cruft from the Ada design, please? :-) > > (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). > At a minimum, you > have to have a way to specify the encoding of files, streams, and hardware > interfaces > That will greatly complicate the interface and > implementation of the libraries. i don't think so. it's a matter of interfacing libraries, for the purpose of communicating with the outside (neither of internal libraries nor of the choice of the internal type for the implementation). Ada.Text_IO.Open.Form already allows (a part of?) this (on the content of the files, not on their name), see ARM A.10.2 (6-8). (write i the reference to ARM correctly?) > > > ... 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. I completely agree :-) > 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. sorry, i meant "garbage collector" in a generic sense, not in a traditional sense. that is, as Ada users we could program with pointers and pool, without memory leaks nor calling Unchecked_Deallocation. for example Ada.Containers.Indefinite_Holders. i already wrote one for constrained limited types. do you know if it's possible to do it for unconstrained limited types, like the class of a limited tagged type? -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/