Re: Lower bounds of Strings

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2021-01-07 01:17, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:rt3uv2$1nrd$1@gioia.aioe.org...
>> On 2021-01-06 04:08, Randy Brukardt wrote:
>>> IMHO, "String" shouldn't be an array at all. In a UTF-8 world, it makes
>>> little sense to index into a string - it would be expensive to do it
>>> based
>>> on characters (since they vary in size), and dangerous to do it based on
>>> octets (since you could get part of a character).
>>
>> It will not work. There is no useful integral operations defined on
>> strings. It is like arguing that image is not an array of pixels because
>> you could distort objects in there when altering individual pixels.
>>
>>> The only real solution is to never use String in the first place. A
>>> number
>>> of people are building UTF-8 abstractions to replace String, and I expect
>>> those to become common in the coming years.
>>
>> This will never happen. Ada standard library already has lots of integral
>> operations defined on strings. They are practically never used. The UTF-8
>> (or whatever encoding) abstraction thing simply does not exist.
>>
>>> Indeed, (as I've mentioned before) I would go further and abandon arrays
>>> altogether -- containers cover the same ground (or could easily) -- the
>>> vast
>>> complication of operators popping up much after type declarations,
>>> assignable slices, and supernull arrays all waste resources and cause
>>> oddities and dangers. It's a waste of time to fix arrays in Ada -- just
>>> don't use them.
>>
>> How these containers are supposed to be implemented?
> 
> Built-in to the implementation, of course. Implementing these things in Ada
> is a nice capability, because that allows simple quick-and-dirty
> implementations. But for things that are commonly used, that necessarily
> leads to lousy performance. One has to have at least some special cases even
> for the Ada.Containers to get adequate performance, so there's no problem
> extending that.

OK, they cannot be implemented in this new Ada. How is that different to 
the present status? Drop features and make syntax ugly is that all?

> ...
>> How Stream_Element_Array is supposed to be an opaque container?
> 
> It should already be an opaque container. You use language-defined stream
> attributes to implement user-defined stream attributes - not unportable
> direct byte twiddling.

No, you are talking about stream here, I am about Stream_Element_Array.

>> How file read operation is supposed to assign part of a container?
> 
> ??? Why would you want to do that?

Well, to read a chuck of data from the socket. Where it goes?

> Streaming a bounded vector (which almost
> all existing arrays should be) naturally would read only the active part of
> the vector.

What is active part of vector? Does it have some type? How do I pass it 
to a subprogram?

> Non-streaming reading is left over Ada 83 nonsense; all I/O
> should be built on top of streams (as a practical matter, the vast majority
> is anyway).

No physical I/O is stream with very rare exceptions.

>> You cannot rid of array interface with all its types involved: index,
>> index set (range), element, element set (array). A containers without the
>> array interface cannot replace array. Any language must support them. The
>> problem is that Ada has array interfaces once built-in and as an ugly lame
>> monstrosity of helper tagged types, a mockery of array.
> 
> There no reason that a container interface cannot have those things --
> Ada.Containers.Vectors does.

As array it is unusable.

> The things that Vectors is missing (mainly the
> ability to use enumeration and modular indexes) was a mistake that I
> complained about repeatedly during the design, but I lost on that.

It has all disadvantages of being no array and no advantages of being a 
tagged type. I do not see how two bad could make one good.

>> Array implementation is a fundamental building block of computing.
> 
> Surely. But one does not need the nonsense of requiring an underlying
> implementation (which traditional arrays do) in order to get that building
> block. You always talk about this in terms of an "interface", which is
> essentially the same idea. One cannot have any sort of non-contigious or
> persistent arrays with the Ada interface, since operations like assigning
> into slices are impossible in such representations. One has to give those
> things up in order to have an "interface" rather than the concrete form for
> Ada arrays.

No, one should have interfaces for such operations as well. You cannot 
do that with a single type and single dispatch. That is another reason 
why you cannot replace built-in arrays with anything before you resolve 
the type system issues. The elephant is the room is that you cannot 
spell array type in Ada. So your solution is supposed to be let's have 
no arrays. That is no solution at all.

> I prefer to not call the result an array, since an array implies a
> contiguous in-memory representation. Of course, some vectors will have such
> a representation, but that needs to be a requirement only for vectors used
> for interfacing. (And those should be used rarely.)

And how these special vectors will differ from other vectors? If Read 
takes special vector (does it?) can I pass a non-special vector instead? 
It leaks. Ada 83 resolved all this per compiler magic. Modern Ada has 
nothing more to offer.

>> That does not go either. Of course you could have two languages, one with
>> arrays to implement containers and one without them for end users. But
>> this is neither Ada philosophy nor a concept for any good
>> universal-purpose language.
> 
> Compilers implement arrays in Ada; there is no possibility a user doing it.
> I see no difference between that and having the compiler implement a bounded
> vector instead as the fundamental building block.

See above. Is bounded vector a vector? No, you cannot make it. So you 
are right back with ugly half-baked arrays named bounded vectors and 
even uglier unbounded vectors with zillion generic functions to convert 
one to another.

> You seem fixated on the
> form of declaration (that is a generic package vs. some sort of built-in
> syntax) -- there's no fundamental difference.

If syntax were the only problem it would be easy to resolve by adding it 
to generics. The problem is not syntax but lacking functionality and 
types and subtypes involved. Generics simply cannot do anything 
resembling Ada 83 arrays.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de