Re: Lower bounds of Strings

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

On 2021-01-07 23:03, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:rt6ltg$922$1@gioia.aioe.org...
> ...
>> 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.

Ada 83 achieved that goal easily while having most of array interfaces 
implemented. The missing interfaces were subarrays and planes of 
multidimensional arrays and proper types of index ranges.

> Any sort of multiple inheritance (not to mention multiple dispatch) requires
> searching a lookup table for the appropriate interface. That is unaccepably
> expensive for an operation as basic as array indexing. One could use
> just-in-time compilation and similar techniques to reduce those costs, but
> those sort of things are not usable in a ROM environment and are much more
> appropriate for a language like Python.

You are talking here about having run-time classes of array types and 
dynamic dispatch on them. That is another story.

[ Though Ada was not shy of introducing ugly tagged iterators, if one 
can do one, why not another? ]

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

The semantic meaning is defining operations of the type has and the 
class it belongs. With arrays you need that because there are lots of 
type conversions between array and array-related types. Interface is 
mere formalization what can be converted into what. You need that 
regardless the method you implement arrays.

The point is that you cannot throw that away without making your 
containers totally useless, you will end up with the notorious 
"Pascal-arrays" pretty soon.

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

It was not expensive in Ada 83. Speaking of the goals, the goal is to 
have user-defined arrays intermixeable with the built-in ones.

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

About 90% of anything is not possible in the existing form. Without 
slices you must pass arrays bounds (or offset/length) down to each call 
as in C.

+ 100% of bindings are impossible.

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

Remember, we are talking about static cases. Your containers with or 
without generics cannot do dynamic dispatch. So everything is static, 
thus, voilà, it costs nothing.

The problem I see is not performance costs, but the fact nobody know how 
to implement multiple dispatch consistently.

> The language you want is not feasible to implement IMHO. A language without
> a feasible implementation doesn't exist practically, and there's little
> sense in talking about it.

I am pretty much satisfied with Ada 83 arrays. What I want is compiler 
magic open to user-defined types. You propose to kill the first without 
offering the second.

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