Hello,

Following the example section of RM Ada 2022 § 4.3.5 Container
Aggregate, I want to try map aggregates:

453. type Map_Type is private
454. with Aggregate => (Empty => Empty_Map,
455. Add_Named => Add_To_Map);
456.
457. procedure Add_To_Map (M : in out Map_Type; Key : in Integer;
Value : in String);
458.
459. Empty_Map : constant Map_Type;
.... -- End of example code
482. private
....
488. type Map_Type is array (1..10) of String (1..10);
489.
490. procedure Add_To_Map (M : in out Map_Type; Key : in Integer;
Value : in String) is null;
491. Empty_Map : constant Map_Type := (1..10 => (1..10 => ' '));

GNAT 12 reports:

aarm_202x_ch04.adb:491:40: error: container aggregate must use [], not ()
aarm_202x_ch04.adb:491:42: error: choice must be static

The first error seems to say that even Map_Type full view is known in
the private part I can't use assignment with genuine array aggregates.
It is a legal feature or GNAT is puzzled?
Is there an other mean to assign array aggregates?

I can't really figure out the meaning of the second error.
Any idea?

Thanks Pascal.

Blady <p.p11@orange.fr> writes:

> aarm_202x_ch04.adb:491:40: error: container aggregate must use [], not ()

If you look at ARM202x 4.3.5, you'll see that *container* aggregates
must use []. I'm sure there wa a whole lot of argument about this in the
ARG!

Le 19/06/2022 à 16:15, Simon Wright a écrit :
> Blady <p.p11@orange.fr> writes:
>
>> aarm_202x_ch04.adb:491:40: error: container aggregate must use [], not ()
>
> If you look at ARM202x 4.3.5, you'll see that *container* aggregates
> must use []. I'm sure there wa a whole lot of argument about this in the
> ARG!

Yes I was aware of that but I wanted to give Empty_Map its real value of
the full type definition.

My understanding is:
you declare the aggregate aspect as:
type Map_Type is private
with Aggregate => (Empty => Empty_Map,
Add_Named => Add_To_Map);
thus:
MM : Map_Type;
....
MM := [] -- the compiler uses Empty_Map
MM := [1=>"toto", 4=>"titi"]; -- the compiler uses Add_To_Map

now if I declare:
Empty_Map : constant Map_Type := [];
then it could be an recursive infinite call, could be?

Note : in this latter case the compiler issues a ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106031

"Blady" <p.p11@orange.fr> wrote in message
news:t8ml0l$1vo2$1@gioia.aioe.org...
> Hello,
>
> Following the example section of RM Ada 2022 � 4.3.5 Container Aggregate,
> I want to try map aggregates:
>
> 453. type Map_Type is private
> 454. with Aggregate => (Empty => Empty_Map,
> 455. Add_Named => Add_To_Map);
> 456.
> 457. procedure Add_To_Map (M : in out Map_Type; Key : in Integer;
> Value : in String);
> 458.
> 459. Empty_Map : constant Map_Type;
> ... -- End of example code
> 482. private
> ...
> 488. type Map_Type is array (1..10) of String (1..10);

This type is illegal, by 4.3.5(10/5):

If the container type of an Aggregate aspect is a private type, the full
type of the container type shall not be an array type.

The reason for this is obvious in your question: it is ambiguous if an
aggregate is an array aggregate or a container aggregate wherever the full
type is visible, and that is not worth making work (any choice would be a
surprise in some contexts).

Apparently, GNAT failed to check for this error (probably because there
aren't ACATS tests yet for Ada 2022, so errors of omission are very hard to
find, not having a vetted set of tests).

Secondly, early post Ada 2022 AIs have removed the possibility of using a
constant for Empty_Map, since it does nto work with inheritance (and
container aggregates are supposed to work with inheritance). So while GNAT
may allow you to define Empty_Map this way now, it won't for very long. It
will need to be a function.

Randy.

Blady <p.p11@orange.fr> writes:

> Le 19/06/2022 à 16:15, Simon Wright a écrit :
>> Blady <p.p11@orange.fr> writes:
>>
>>> aarm_202x_ch04.adb:491:40: error: container aggregate must use [], not ()
>> If you look at ARM202x 4.3.5, you'll see that *container* aggregates
>> must use []. I'm sure there wa a whole lot of argument about this in the
>> ARG!
>
> Yes I was aware of that but I wanted to give Empty_Map its real value
> of the full type definition.
>
> My understanding is:
> you declare the aggregate aspect as:
> type Map_Type is private
> with Aggregate => (Empty => Empty_Map,
> Add_Named => Add_To_Map);
> thus:
> MM : Map_Type;
> ...
> MM := [] -- the compiler uses Empty_Map
> MM := [1=>"toto", 4=>"titi"]; -- the compiler uses Add_To_Map
>
> now if I declare:
> Empty_Map : constant Map_Type := [];
> then it could be an recursive infinite call, could be?

I think you'd need to supply the contents - Empty_Map here is presumably
the full declaration (it is in your PR). Fixing this, the compiler is
still confused (it thinks that 'others' in [others => [others => ' ']]
isn't static - also if replaced by '1 .. 10'!!!).

It look like the Aggregate aspect has some rough edges.
This code leads to internal compiler error with gnatmake 12.1.0:

package Container_Aggregates is
type Array_Type is
array (1 .. 10) of Integer
with Aggregate => (Empty => Empty_Array);

Empty_Array : constant Array_Type := [1..10 => 123];
end Container_Aggregates;

On 2022-06-20 23:47, Randy Brukardt wrote:

> The reason for this is obvious in your question: it is ambiguous if an
> aggregate is an array aggregate or a container aggregate wherever the full
> type is visible, and that is not worth making work (any choice would be a
> surprise in some contexts).

I don't agree that making the language regular does not worth work. The
choice is obviously inconsistent with handling both existing cases:

1. Built-in operations -> hiding:

type T is private;
function "+" (Left, Right : T) return T; -- Perfectly legal
private
type T is range 1..100;

2. Primitive operations -> overriding.

What's good for the goose is good for the gander? Nope. Here is a
totally new way of handling an operation!

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

tirsdag den 21. juni 2022 kl. 00.10.52 UTC+2 skrev Jesper Quorning:
> This code leads to internal compiler error with gnatmake 12.1.0:

This is the bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106037
The crash happens another place than the #106031 report by Blady.

I ran into a third ICE with erroneous memory access while playing around with an access type.

/Jesper

Thia ia also illegal: the aspect aggregate is defined "for a type other than
an array type", so the aspect should not even be recognized in this context.

Randy.

"Jesper Quorning" <jesper.quorning@gmail.com> wrote in message
news:9e3aa56d-42b3-4552-8027-908403118721n@googlegroups.com...
> tirsdag den 21. juni 2022 kl. 00.10.52 UTC+2 skrev Jesper Quorning:
>> This code leads to internal compiler error with gnatmake 12.1.0:
>
> This is the bug report:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106037
> The crash happens another place than the #106031 report by Blady.
>
> I ran into a third ICE with erroneous memory access while playing around
> with an access type.
>
>
> /Jesper

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:t8qrmo$p79$1@gioia.aioe.org...
> On 2022-06-20 23:47, Randy Brukardt wrote:
>
>> The reason for this is obvious in your question: it is ambiguous if an
>> aggregate is an array aggregate or a container aggregate wherever the
>> full
>> type is visible, and that is not worth making work (any choice would be a
>> surprise in some contexts).
>
> I don't agree that making the language regular does not worth work.

There's always a way, but is it worth the implementation effort? And would
it be confusing to use?

> The choice is obviously inconsistent with handling both existing cases:
>
> 1. Built-in operations -> hiding:
>
> type T is private;
> function "+" (Left, Right : T) return T; -- Perfectly legal
> private
> type T is range 1..100;

This case is not worth the effort, IMHO. (Of course, it is in the language
now, so we're stuck with it.) If I was running the circus, private types
could only be completed with a record type. 99% of the time, that's what you
want. And the other 1% of the time, you will eventually end up changing it
into a record for one reason or the other. So why pollute the language rules
for something primarily useful in ACATS tests?

> 2. Primitive operations -> overriding.
>
> What's good for the goose is good for the gander? Nope. Here is a totally
> new way of handling an operation!

The problem here is illustrated by the OP, who seemed to expect to get the
container aggregate when the full view is visible. We looked at making the
container aggregate invisible and allowing the array aggregate in the full
view, but it would be something new (the contents of aggregates don't depend
on visibility in Ada 2012), and it seems useless (see my answer to [1]).

That is, the OPs construct is primarily useful in small examples; it's not a
real world thing you would want to do. (There ALWAYS is some other data that
you need to go along with an array: a length, a validity flag, etc.) So why
make implementers spend a lot of effort implementing it??

Randy.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:t8qrmo$p79$1@gioia.aioe.org...
....
> 1. Built-in operations -> hiding:
>
> type T is private;
> function "+" (Left, Right : T) return T; -- Perfectly legal
> private
> type T is range 1..100;
>
> 2. Primitive operations -> overriding.

BTW, these two are really the same thing. In the first example, the "+" is
overriding the predefined operation.

But note an important difference here from the aggregate case: in no case is
an operation available for the private type that is *not* available for the
full view. Since the syntax and semantics of container aggregates and array
aggregate are subtly different (they are as close as we could make them, but
that is not that close), there definitely are things that would be only
possible when written for the private view. That would be new for Ada. So
while a definition could be made, it would be confusing in some cases. And
this case isn't useful enough to make that effort.

BTW2, there are many things in Ada that would be possible with effort but
are illegal for one reason or another. Part of the reason for doing that is
that it is always possible to allow such things in the future -- that would
be a compatible change. OTOH, defining them sloppily would leave us stuck
forever with an expensive and relatively useless feature. For instance, the
rather strict limitations on the use and contents of a declare expression
fall into that category. Allowing more would be possible, but it would have
far-reaching effects on compilers and on the language definition. Not worth
the cost at this point, perhaps that will change.

Randy.
..

On 2022-06-22 01:39, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:t8qrmo$p79$1@gioia.aioe.org...
> ...
>> 1. Built-in operations -> hiding:
>>
>> type T is private;
>> function "+" (Left, Right : T) return T; -- Perfectly legal
>> private
>> type T is range 1..100;
>>
>> 2. Primitive operations -> overriding.
>
> BTW, these two are really the same thing. In the first example, the "+" is
> overriding the predefined operation.

Yes, they should be in a better world. A primitive operation is always
reachable. The case above works differently from:

type T is private;
overriding
function "+" (Left, Right : T) return T is abstract;

But this is a deeper problem of having such operations primitive.

> But note an important difference here from the aggregate case: in no case is
> an operation available for the private type that is *not* available for the
> full view. Since the syntax and semantics of container aggregates and array
> aggregate are subtly different (they are as close as we could make them, but
> that is not that close), there definitely are things that would be only
> possible when written for the private view. That would be new for Ada. So
> while a definition could be made, it would be confusing in some cases. And
> this case isn't useful enough to make that effort.

Much could be resolved by attributing proper types to all assumed or
real intermediate steps:

type T is private;
function "+" (Left, Right : T) return T;
private
type T_Parent is range 1..100;
type T is new T_Parent;

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

On 2022-06-22 01:28, Randy Brukardt wrote:

> This case is not worth the effort, IMHO. (Of course, it is in the language
> now, so we're stuck with it.) If I was running the circus, private types
> could only be completed with a record type.

Just like aggregates now, record types *must* have interface. Your
"circus" will inevitable face this same problem again - how to define
record members of a private type implemented by a built-in record type
in the full view? The language must universally handle all sorts of
interfaces.

> The problem here is illustrated by the OP, who seemed to expect to get the
> container aggregate when the full view is visible. We looked at making the
> container aggregate invisible and allowing the array aggregate in the full
> view, but it would be something new (the contents of aggregates don't depend
> on visibility in Ada 2012), and it seems useless (see my answer to [1]).

I would first answer basic questions, which interfaces have array vs
user-defined aggregate/index. How are they related to each other etc.

> That is, the OPs construct is primarily useful in small examples; it's not a
> real world thing you would want to do. (There ALWAYS is some other data that
> you need to go along with an array: a length, a validity flag, etc.) So why
> make implementers spend a lot of effort implementing it??

Well, I can give a useful example straight away. A string has two array
interfaces, the encoding and the character view. The former must be a
built-in array.

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:t8ulu9$jca$1@gioia.aioe.org...
> On 2022-06-22 01:28, Randy Brukardt wrote:
....
> Well, I can give a useful example straight away. A string has two array
> interfaces, the encoding and the character view. The former must be a
> built-in array.

The interface for a string should be quite different from that for an array,
they're not related at all. One might implement a string with a record type
that has an array component, but never as a bare array. (That leads to
nonsense, which Ada sadly has proven clearly.

Indeed, if you consider everything to have an interface, arrays themselves
cease to be a fundemental part of a language design and just become another
interface. (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.)

Randy.

Randy.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:t8ujnr$1hvf$1@gioia.aioe.org...
> On 2022-06-22 01:39, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:t8qrmo$p79$1@gioia.aioe.org...
>> ...
>>> 1. Built-in operations -> hiding:
>>>
>>> type T is private;
>>> function "+" (Left, Right : T) return T; -- Perfectly legal
>>> private
>>> type T is range 1..100;
>>>
>>> 2. Primitive operations -> overriding.
>>
>> BTW, these two are really the same thing. In the first example, the "+"
>> is
>> overriding the predefined operation.
>
> Yes, they should be in a better world. A primitive operation is always
> reachable. The case above works differently from:
>
> type T is private;
> overriding
> function "+" (Left, Right : T) return T is abstract;
>
> But this is a deeper problem of having such operations primitive.
>
>> But note an important difference here from the aggregate case: in no case
>> is
>> an operation available for the private type that is *not* available for
>> the
>> full view. Since the syntax and semantics of container aggregates and
>> array
>> aggregate are subtly different (they are as close as we could make them,
>> but
>> that is not that close), there definitely are things that would be only
>> possible when written for the private view. That would be new for Ada. So
>> while a definition could be made, it would be confusing in some cases.
>> And
>> this case isn't useful enough to make that effort.
>
> Much could be resolved by attributing proper types to all assumed or real
> intermediate steps:
>
> type T is private;
> function "+" (Left, Right : T) return T;
> private
> type T_Parent is range 1..100;
> type T is new T_Parent;

Don't think this changes anything (at least not in Ada as it stands), since
that is essentially the meaning of "range 1 .. 100":

type Some_Int is range 1 .. 100;

means

type Some_Int is new <Some_Int_Chosen_by_the_Impl> range 1 .. 100;

Randy.

On 2022-06-23 03:06, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:t8ulu9$jca$1@gioia.aioe.org...
>> On 2022-06-22 01:28, Randy Brukardt wrote:
> ...
>> Well, I can give a useful example straight away. A string has two array
>> interfaces, the encoding and the character view. The former must be a
>> built-in array.
>
> The interface for a string should be quite different from that for an array,
> they're not related at all. One might implement a string with a record type
> that has an array component, but never as a bare array. (That leads to
> nonsense, which Ada sadly has proven clearly.

String is an array of encoding units, historically and practically. Even
at the machine level string instructions deal with arrays.

A language unable to support such implementation does not look usable to me.

> Indeed, if you consider everything to have an interface, arrays themselves
> cease to be a fundemental part of a language design and just become another
> interface.

Everything has interface just because it is the way human brain works.

The language design question is what interfaces deserve to be formalized
and exposed in the language as entities the programmer can reference,
check against etc.

In Ada array interface is exposed in generics as a formal array, but not
in the type system proper.

In any case having an explicit array interface does not preclude
built-in arrays.

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

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

On 2022-06-23 03:10, Randy Brukardt wrote:

> Don't think this changes anything (at least not in Ada as it stands), since
> that is essentially the meaning of "range 1 .. 100":
>
> type Some_Int is range 1 .. 100;
>
> means
>
> type Some_Int is new <Some_Int_Chosen_by_the_Impl> range 1 .. 100;

I mean that then we would have two distinct types to assign conflicting
operations to. So "+" each goes to a separate type.

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

On 23.06.22 11:32, Dmitry A. Kazakov wrote:

> In any case having an explicit array interface does not preclude built-in arrays.

Indeed, if there were no built-in arrays, how would one

- specify aspects like "contiguous memory",
- permit implementations to create efficient addressing
for arrays' storage units
- map to hardware?

"G.B." <bauhaus@notmyhomepage.invalid> wrote in message
news:t91gmo$rh1$1@dont-email.me...
> On 23.06.22 11:32, Dmitry A. Kazakov wrote:
>
>> In any case having an explicit array interface does not preclude built-in
>> arrays.
>
> Indeed, if there were no built-in arrays, how would one
>
> - specify aspects like "contiguous memory",
> - permit implementations to create efficient addressing
> for arrays' storage units
> - map to hardware?

With aspects, of course, that are part of the "interface". Why do you think
that one needs a visible built-in array in order to support these (or any
other) operations?

Again, at the implementation level, surely there is some sort of built-in
array. But one does not need to expose that at the programmer level.
"Efficient addressing" is the compiler's job, it will do whatever makes
sense for the target (and those vary quite a bit).

For example, "contiguous" is an aspect that Ada is missing (but should
have). Implementations should have the freedom to pick any implementation in
the absence of such as aspect (which should be rarely needed, mainly for
interfacing with hardware and foreign software).

Mapping to hardware could be handled with a "fixed vector" container (one
that would be rarely used other than for interfacing). It doesn't require an
array, just something with the right semantics.

Randy.

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

Randy.

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

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

On 2022-06-25 05:13, Randy Brukardt wrote:
> "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:

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

No. Identifier is not a value, it is a static name. This allows us to
have any statically chosen type on the right side of the mapping.

With a dynamic mapping we must have the same type for all outcomes, e.g.
of the array element.

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

We have different priorities here. I see arrays with slices as one of
the most important language features. Especially considering formal
verification and validation.

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

No, I worry about cost of execution. You want to simplify the compiler
at the expense of the program complexity and efficiency of its code.

> I'd rather plan for a future where the compiler tool set does a lot of
> correctness checking for one's programs;

Yes and correctness checking requires proper and very refined
abstractions you are ready to throw away. Here is a contradiction. In a
language like Forth there is basically nothing to check.

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:t96i9f$1mc1$1@gioia.aioe.org...
> On 2022-06-25 05:13, Randy Brukardt wrote:
....
>> 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).
>
> No, I worry about cost of execution. You want to simplify the compiler at
> the expense of the program complexity and efficiency of its code.

I think we strongly agree here. I want to simplify the front-end to
strengthen abstractions, and so that the effort can be put where it belongs,
on static analysis/optimization and on code generation. These things are
mostly fancy pattern matching, and the more of it that you can do, the
better. Time spent implementing features that don't increase the expressive
power (or worse, compilicate code generation in all cases) is
counter-productive.

>> I'd rather plan for a future where the compiler tool set does a lot of
>> correctness checking for one's programs;
>
> Yes and correctness checking requires proper and very refined abstractions
> you are ready to throw away. Here is a contradiction. In a language like
> Forth there is basically nothing to check.

Slices are not an abstraction. They are a way to describe a particular kind
of processor operation in a vaguely abstract way. But they don't extend to
user-defined structures or even multi-dimensional maps (arrays if you
prefer) in any practical way. The distributed overhead that they cause is
immense (for instance, you can't have a discontigious array represesentation
with slices, unless you are willing to pay a substantial cost for *every*
array parameter). They're the anti-abstraction feature.

Randy.

On 2022-06-28 0:37, Randy Brukardt wrote:
>
> Slices are not an abstraction. They are a way to describe a particular kind
> of processor operation in a vaguely abstract way.

The abstraction is the concept of a one-dimensional array (a vector or a
sequence). Slicing such an object -- taking a subsequence -- seems a
very natural operation to me, even on the abstraction level.

> The distributed overhead that they [slices] cause is immense (for
> instance, you can't have a discontigious array represesentation with
> slices,

Why would you want to have a non-contiguous representation for
one-dimensional arrays? Perhaps to make "unbounded" (extensible) arrays?