Re: New aggregates with Ada 2022.

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

On 2022-06-24 03:24, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:t91buq$10im$1@gioia.aioe.org...
>> On 2022-06-23 03:06, Randy Brukardt wrote:
> ...
>>> (How something gets implemented should not be part of a language
>>> design, so long as the design does not prevent an efficient
>>> implementation.)
>>> I certainly would not treat them as special in any way, just a series of
>>> function calls. (Possibly records could be treated that way as well,
>>> although it is less clear that an efficient implementation is possible
>>> for
>>> them.)
>>
>> Syntax sugar for subprogram calls is not enough because it does not allow
>> generic programming. One should be able to write a program that deals with
>> any instance of the interface. Like a generic body working with any actual
>> array or a class-wide body which unfortunately is impossible to have for
>> arrays presently.
> 
> You're thinking too small. Obviously, in a language without an syntactic
> array construct, every data structure would be some sort of record.

They are fundamentally different. Record interface is static mapping:

    identifier -> value

1D array interface is dynamic mapping:

    ordered value -> value

It not only has run-time semantics of (indexing). It is also ordering of 
the index which implies enumeration, ranges, slices.

> So
> class-wide operations would be available for all of those -- and without all
> of the complications of a separate formal array type. The idea is to have
> one mechanism for pretty much everything, and let the compiler sort out the
> results. Back when we created Janus/Ada, that wasn't really practical
> because of memory and CPU speed constraints, but none of that holds true
> anymore. Simplify the language, complicate the compiler!

I don't buy the idea of run-time penalty for having abstract data types 
and I don't see why built-in arrays cannot coexist with user-defined 
ones without turning the language into LISP. Furthermore, the age of 
free CPU cycles came to an end. Soon we will have return back to sanity.

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