Re: Lower bounds of Strings

[Shark8 <onewingedshark@gmail.com>]

On Thursday, January 7, 2021 at 3:03:54 PM UTC-7, Randy Brukardt wrote:
> "Dmitry A. Kazakov" wrote in message
> news:rt6ltg$922$... 
> ...
> > No, one should have interfaces for such operations as well.
> You're again losing sight of the ultimate goal here, which is to have a 
> conventionally compiled language that works close to the metal for high 
> performance. (And is compatible with embedded systems, runable from ROM, 
> etc.) 
> 
> Interfaces of any kind are completely counter to that goal, *especially* in 
> the case of arrays/vector containers.
Why?
An interface, in abstract, says very little about the implementation; it's essentially equivalent to the "set of operations" side of the working-definition of a Type: "A set of possible values and a set of operations on those values." — And aren't arrays commonly used in high-performance, "close to the metal" computing all the time?

It's also easy to imagine a wizard/database system which selects the proper structure/set-of-structures for you given the constraints requested; in psudeo-SQL:
Select from Structures where Look_up.Maximum <= Linear and Deletion.Average <= Linearithmic;

Combining these two: you could, with an abstract interface, have a system that chose an underlying/implementation structure given the requisite properties, of which the interface could be a part. Similar to Ada's Generic parameter "Type X is private" indicating any type which has assignment.

> Any sort of multiple inheritance (not to mention multiple dispatch) requires 
> searching a lookup table for the appropriate interface.
Ah.
It appears you're confusing the Ada concept underlying keyword INTERFACE with the general/abstract notion.
It appears to me that Dmitry is referring to the latter, not the Ada-construct of INTERFACE, which requires a tagged type.

I think what he's getting at is something that I considered/proposed here on C.L.A some years ago, adding the concept of an "ABSTRACT INTERFACE" to Ada. (IIRC, the proposal I had in mind was to be able to model the notional meta type-hierarchy; eg: Number ⊃ Universal_Integer ⊃ System.Integer.)

> If you aren't using the interface as such (that is, with some form of 
> dispatching), then it is simply a complication with no semantic meaning. 
> There's no problem thinking about concepts as some sort of logical 
> interface, but it is a distinction without meaning in that case. (By that 
> logic, Ada 202x has interfaces for Image, indexing, dereferencing, literals, 
> and streaming that can be applied to any tagged type.) 
I don't think he is talking about dispatching.
I also don't think that we need to *have* dispatching to have classes-of-types; the generic formal parameters exemplify that.

> 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 think it would be interesting to also have a sort of "ABSTRACT TYPE" that could allow an Ada compiler/wizard-system (as mentioned above) fill in the gap with some appropriately matching type; this would be good for the usage of prototyping, and probably also optimization, to have a way to say "I need something that I can insert elements into, delete them, and index into, but will never exceed 2**8 items." -- though this might be a bit too much for some people/applications, especially those in fields where you commonly specify bit-patterns and the like (there are times for those, but unless you're doing the low-level stuff, you probably should let the compiler work things out).
 
> BTW, you have yet to show me any useful example that you can't reasonably do 
> with a bounded vector (assuming that vector supports any discrete index 
> type). For almost any possible language feature, there's always some example 
> where it works better than the alternative using the basic features of the 
> language. But that's not the question, the question is whether it is worth 
> it in terms of language complexity, opportunity cost (time spent 
> implementing feature X is time not spent on features A, B, and C), and 
> usability (too many special case features make it harder to learn and use a 
> language). 
True, but making an appropriately abstract/general feature can allow you to subsume/replace older features, defining them in terms of the new feature.
If the ARG were more open to the idea of removing language features, we could be a bit more aggressive here; but that would mean breaking backwards-compatibility, which is rather unpopular.

> 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?

> 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.

> > You cannot do that with a single type and single dispatch.
> Exactly my point. The implementation of multiple inheritance and multiple 
> dispatch is simply too expensive for a language like Ada, and that's 
> especially true in the case of basic building blocks like arrays/vectors.
Some of the MI/MD motivation seems to be unnecessarily complicated, in addition to the inherent complications.
Though I do like the PRINT: PRINTER x IMAGE example, where you have the class of images and the class of printers for the parameters of Print, and there are good reasons for choosing to resolve first the printer or the image.