Re: Proposal: Auto-allocation of Indefinite Objects

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

On 23/08/2020 06:48, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:rhnqjf$bga$2@gioia.aioe.org...
>> On 21/08/2020 01:30, Randy Brukardt wrote:
> ...
>>> There's no reason that a compiler couldn't "build-in" a simple bounded
>>> vector container as the basic building block.
>>
>> That simply replaces the word "array" with four words "simple bounded
>> vector container." The construct is still there and it is still built-in.
>> The syntax and usability are drastically worse, though.
> 
> ??? The syntax of use is the same (as it is in Ada 2012). Declaration would
> be an instance,

That alone disqualifies it in my eyes.

> about the same length and wordiness as an array declaration.

Plus a dozen of tagged helper types...

> Yes, junk like slices, settable/retrievable bounds, and built-in operations
> that are rarely used would be gone, but so would the rather substantial
> overhead that those things entail. There'd be a lot more flexibility in
> implementation, which would allow better implementations.

These is a vital part of array interface to me. Moreover I want lost of 
other junk there, like ranges being proper types, like multidimensional 
slices/subarrays, indicator sets (to specify array's diagonal) etc.

> Virtually every array that I write has a fixed size (capacity really) and a
> usage high-water mark (a "length"). Having that generated automatically
> would be usually better than having to reinvent it literally every time I
> program something. (And as you've noticed repeatedly, Ada's type abstraction
> isn't good enough to make it practical to build anything reusable to do
> that.)

I agree with that, but disagree with the solution. In my view arrays 
must be 1) generalized, 2) abstracted to support user-defined 
implementations.

The challenge is to have a type system where one could design a 3-band 
matrix type usable where a dense matrix type is expected.

>>> One could do something similar for records, although I would probably
>>> leave
>>> them as in Ada and just allow user-definition of "." (via a getter/setter
>>> pair).
>>
>> Ditto.
> 
> ???
> 
> The basic idea would be to eliminate the huge number of special cases that
> exist in Ada resolution and essentially make *everything* a subprogram call
> at it's heart.

Yes, I agree everything must have a corresponding primitive operation. 
But there are cases when such operations must be static like "." of a 
record types or implemented per delegation to a generalized 
implementation like integer or string literals.

> Ada did that for enumeration literals and that model makes
> sense for pretty much everything: object usage, indexing, selection, etc. It
> would be much easier to prove that resolution is doing the right thing (I
> don't think that would be practically possible for Ada).

I think that not only Ada's, but even C++'s type system, could be 
expressed by means of a more powerful one. After all it is possible to 
write a compiler for both...

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