In article <s5vpul$ldb$1@franka.jacob-sparre.dk>,
"Randy Brukardt" <randy@rrsoftware.com> wrote:

> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
> news:ie8uagFqaf2U1@mid.individual.net...
> > On 2021-04-20 23:32, Jeffrey R. Carter wrote:
> >> On 4/20/21 8:53 PM, Randy Brukardt wrote:
> >>>
> >>> 'Free makes more sense in a new language (an Ada follow-on).
> >>
> >> Right. I don't think it would be a good idea to add it to Ada.
> >>
> >> But I think a new language should not have pointers at all.
> >>
> >> No more radical than not having arrays.
> >
> > It seems to me that a language without arrays and pointers would be very
> > difficult to use in an embedded, real-time, close-to-HW context. So we
> > would lose the nice wide-spectrum nature of Ada.

i like "the nice wide-spectrum nature of Ada" :-)
If I got it right, it is the thickness*, that is, it goes both far in
low level and far in high level.

* Natacha Porte, https://www.youtube.com/watch?v=b5lRyBRk0d8&t=430s
(during 1:10 - sorry, it's only in french)

>
> It's important that a new language have a way to interface to existing
> hardware and software. So there has to be something that maps to C arrays
> and pointers (and the equivalent for hardware). But that doesn't necessarily
> have to be something that is used outside of interfacing. An Ada example is
> Unchecked_Unions -- they exist for interfacing but shouldn't be used
> otherwise.

i don't know much "exotic things" (for me) like embedded or real-time
programming,
but i would not take the risk to exclude users who need low level in
various cases (not only in interfaces),
so i think it would be better to keep a full thickness with the ability
to go far in low level at any place it is considered usefull.

> A fixed vector type and a raw general access type would do the
> trick, but those could be something that are almost never used outside of
> interfacing packages.

an other point here, is the ability to create new structures that could
be considered as "basic" later.

for example Ada.Containers.Multiway_Trees seems to be based on
Ada.Containers.Doubly_Linked_Lists,
and i don't know if it could be needed / usefull to have trees based on
Ada.Containers.Vectors,
but based on Ada.Containers.Ordered_Maps, certainly!

and sometimes using other high level data structures would be enough,
but probably sometimes it would be non-optimal, and maybe, in the worst
case, it could be impossible (especially in the event that we had not
foreseen all the needed high level data structures)

so, i think:

- we could keep arrays as is, no matter if they are rarly used.

- for access types, it would be nice to find a kind of "controlled
access type" that allows:
- to access the "raw general access type", as low level type,
when needed,
- to need not Unchecked_Deallocation, making automatic Deallocation,
- and which would not be too much high level
(for example Ada.Containers.Indefinite_Holders is fine).

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/