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=-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: Wed, 6 Apr 2022 20:30:58 -0500 Organization: A noiseless patient Spider Message-ID: References: <607b5b20$0$27442$426a74cc@news.free.fr> <86mttuk5f0.fsf@stephe-leake.org> Injection-Date: Thu, 7 Apr 2022 01:31:00 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="65c7ce06d269e04522287d23acb2d265"; logging-data="13391"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/4MVNPs6WAd0AYgGrVuYsfTwdUVtSSj8w=" Cancel-Lock: sha1:4oLs51vIh+kTiUig6vOfhipRC6g= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-RFC2646: Format=Flowed; Response X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-Priority: 3 X-MSMail-Priority: Normal Xref: reader02.eternal-september.org comp.lang.ada:63709 List-Id: "J-P. Rosen" wrote in message news:t2knpr$s26$1@dont-email.me... ... > It was felt that in practice, being too strict in separating the types > would make things more difficult, without any practical gain. This has > been discussed - you may not agree with the outcome, but it was not made > out of pure lazyness The problem with that, of course, is that it sends the wrong message vis-a-vis strong typing and interfaces. If we abandon it at the first sign of trouble, they we are saying that it isn't really that important. In this particular case, the reason really came down to practicality: if you want to do anything string-like with a UTF-8 string, making it a separate type becomes painful. It wouldn't work with anything in Ada.Strings, Ada.Text_IO, or Ada.Directories, even though most of the operations are fine. And there was no political will to replace all of those things with versions to use with proper universal strings. Moreover, if you really want to do that, you have to hide much of the array behavior of the Universal string. For instance, you can't allow willy-nilly slicing or replacement: cutting a character representation in half or setting an illegal representation has to be prohibited (operations that would turn a valid string into an invalid string should always raise an exception). That means you can't (directly) use built-in indexing and slicing -- those have to go through some sort of functions. So you do pretty much have to use a private type for universal strings (similar to Ada.Strings.Bounded would be best, I think). If you had an Ada-like language that used a universal UTF-8 string internally, you then would have a lot of old and mostly useless operations supported for array types (since things like slices are mainly useful for string operations). So such a language should simplify the core substantially by dropping many of those obsolete features (especially as little of the library would be directly compatible anyway). So one should end up with a new language that draws from Ada rather than something in Ada itself. (It would be great if that language could make strings with different capacities interoperable - a major annoyance with Ada. And modernizing access types, generalizing resolution, and the like also would be good improvements IMHO.) Randy.