Re: New aggregates with Ada 2022.

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:t93mr6$pvm$1@gioia.aioe.org...
> 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.

Dymanic means a function. And there is no reason to treat a few functions as 
special (again, at the user level).

Something purely-compile time (like the selection of record components) 
clearly needs some special semantics. Not so clear with dynamic things.

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

They add a huge amount of complication for very little gain. One could 
simplify them (getting rid of mistaken features like slices), but you still 
would want a user-defined version. And once you have that, you no longer 
need a special version - you just have some predefined versions (just like 
Ada handles operators).

> Furthermore, the age of  free CPU cycles came to an end. Soon we will have 
> return back to sanity.

I don't think programming abstractly and translating that into good code 
will ever be a bad idea. After all, that is the idea behind Ada. If you 
truly want to worry about the cost of compilation, then you have program in 
a very close to the metal language, even lower level than C. And current 
machines are way harder to generate code for than the Z-80 that we started 
out on (and even then, we generated pretty bad code with the very tiny 
compiler).

I'd rather plan for a future where the compiler tool set does a lot of 
correctness checking for one's programs; code generation will always be much 
cheaper than that (especially if you do not need bleeding edge performance). 
Simplify (and abstract) the language, complicate the compiler!

                                                          Randy.