Re: Lower bounds of Strings

[Shark8 <onewingedshark@gmail.com>]

On Friday, January 8, 2021 at 7:31:40 PM UTC-7, Randy Brukardt wrote:
> "Shark8" wrote in message 
> news:37ada5ff-eee7-408...
> 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.
But that's the point, it's not about them having a dynamic presence, it's about the ability to classify and categorize.
Kind of like how SPARK's Ghost-code is there to help the prover, not be part of the actual program. Likewise, these ABSTRACT INTERFACES are about making an interface into a type, and doing so consistently, language-wide; kind of like how the containers use special aspects, and also like how generic formal parameters provide minimal information [to the implementation] the less-definite you get.

Perhaps a psuedo-Ada example would work.

Abstract Type DISCRETE_ITEM is (<>);
Abstract Type CONSTRAINED_ITEM is private;
Abstract Type ARRAY_ITEM( Index : DISCRETE_ITEM; Element : CONSTRAINED_ITEM ) is private
  with Access => Element At ARRAY_ITEM(Index); -- Get an ELEMENT by accessing through Index.

>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.
The idea here is to build a system wherein you can (a) define the interfaces of any type, (b) give names to the notional entities [like Universal_Integer], (c) have a construct that is itself robust/provable enough that you can use it to describe/redefine Ada's type-system in its terms, allowing the subclause to be shortened [hopefully], machine translatable, and machine provable.

Much like moving from:
  Function Foo( I : Integer ) return Natural;
  * Foo's parameter must be in the range of -1 and System.Integer'Last;
  * Exception Program_Error is raised on any negative number, except -1.
to:
  Function Foo(I : Integer) return Natural
    with Pre => I in -1..System.Integer'Last or else raise Program_Error;
eliminates English verbiage in favor of language-defined constructs can [hopefully] reduce the size/complexity of the standard, as well as increase the machine-translatability,

> 
> ...
> >> 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.
What do you mean "super-null" nonsense?

>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.
Pretty much the only times I've used slicing [aside from "copy me this substring, and continue on"] have been windowing, though that's typically with a renames.

> 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.
Ah, I think I see now.

> >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).
Why wouldn't it?
UTF- 8, and UTF-16 are both 8/16 bits, so their underlying "sequence of codepoints" should be 8/16... but then, Unicode makes everyone's lives harder while pretending to be helpful.

>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.
Right, which is why if I could I'd 'collapse' the [[Wide_]Wide_]String into a single generic, then we would have less to maintain.
GNAT, for example is *still* missing Wide_Wide_Equal_Case_Insensitive.

> (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. 
True, but my usage is typically either ASCII, LATIN-1, or Wide_Wide_Character.