Re: Lower bounds of Strings

["Randy Brukardt" <randy@rrsoftware.com>]

"Shark8" <onewingedshark@gmail.com> 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.