From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Lower bounds of Strings Date: Fri, 8 Jan 2021 20:31:37 -0600 Organization: JSA Research & Innovation Message-ID: References: <1cc09f04-98f2-4ef3-ac84-9a9ca5aa3fd5n@googlegroups.com> <37ada5ff-eee7-4082-ad20-3bd65b5a2778n@googlegroups.com> Injection-Date: Sat, 9 Jan 2021 02:31:38 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="28129"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:61071 List-Id: "Shark8" wrote in message news:37ada5ff-eee7-4082-ad20-3bd65b5a2778n@googlegroups.com... On Thursday, January 7, 2021 at 3:03:54 PM UTC-7, Randy Brukardt wrote: .... >> So either you are talking about a complication without value, or an >> extremely expensive implementation that doesn't meet the goals for a >> language like Ada. What's the point? >In the matter of the "ABSTRACT INTERFACE" idea, we could define >things in such a way at the language level that: > (1) we could specify the notional types (eg Universal_Float, > Universal_Fixed, etc) >in this system, providing the interface of that type for the usage of the >language; > (2) the specification of these notional-types would allow for less > verbiage in the > standard, and possibly allow proving on the classes they encompass. I again don't see the point. The thing that you can't do with the Ada universals is name them, because they don't have a dynamic presence. There's no problem proving anything with them, they're already explicitly defined in the RM. All you would be doing is changing the syntax in the subclauses of 4.5. For a totally new language, that might be useful, but I fail to see any benefit for Ada -- it's a lot of work without changing much of anything. ... >> Slices fall on the wrong side of this boundary for me; the nonsense >> required >> to implement them seems reasonable at first but rapidly disappears as of >> the >> many other things that cannot be done in their presense. >Can you give some examples here? All of the super-null nonsense occurs because of slices, which slows down any code that uses them. And they are designed to be a "window" into an existing contiguous single-dimensioned array. But syntactically, they appear to be some sort of general concept. Which is why you always hear people talking about slices of multi-dimensional arrays. But those would require dealing with discontiguous chunks of an array, which would have a heavy distributed overhead (since you can assign into them, just making a copy isn't an implementation option). So you would have to pass an assignment "thunk" (compiler-generated subprogram) with any writable array parameter -- even if you never, ever passed a slice to that parameter. The cost would be massive. Any sort of consistent slice interface would run into the same problem, since you always want the invariant that A(1..3) = A(1) & A(2) & A(3) and that is extremely difficult to do with writable slices. If you could only *read* a slice (which would cover 90% of the uses), things would be better. But I doubt anyone wants to go in that direction. >> And they're mainly useful for strings, which are not arrays to begin >> with. >The proliferation of strings in Ada is lamentable; I would love to be able >to >have a set of generics so you could instantiate with >[[Wide_]Wide_]Character >and get the current-Ada hierarchy. That wouldn't work for UTF-8 and UTF-16, which makes it pointless at this point. The default String should be UTF-8, the others should be reserved for special cases (interfacing in particular). You don't want the default string type to restrict the contents, and you don't want it to waste a lot of space. As Dmitry has said in the past, operations that go at a character at a time through a string are rare, and most of those are properly implemented in Ada.Strings -- users shouldn't be reinventing those wheels in the first place. (That's especially true as many of them can do octet operations rather than character indexing.) So UTF-8 is the best trade-off for general use. Randy.