In article <s5h0o5$1piu$[email protected]>,
"Dmitry A. Kazakov" <[email protected]> wrote:

On 2021-04-18 11:09, Jeffrey R. Carter wrote:

On 4/18/21 10:46 AM, Gautier write-only address wrote:

Side note: did anyone already suggest a new keyword: unchecked_free
and a special statement:

   unchecked_free Some_Pointer;

For every access variable P, there could exist the attribute procedure

  P'Free;

I like the idea of attaching it to a variable rather than to type.

why?

if it had to be made, i would say it could not be less than sth like: T'Unchecked_Free (P)

-------------
I remember the claim that originally making it a generic procedure with
an indigestible name was meant as barrier for lazy programmers.

not only that:
i agree J-P. Rosen (he didn't said exactly that),
it's fine to be able to search for the "Unchecked" keyword, to look at
parts of code with some known risk (afaik):
Ada.Unchecked_Deallocation, Ada.Unchecked_Conversion, Unchecked_Access.

Plus
some considerations regarding garbage collection lurked in the subconscious.

could you explain, please ? :-)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>,
Gautier write-only address <[email protected]> wrote:

Well, P'Free can also be in another package... Of course, we are talking here only about the direct, actual deallocation.

If you want to precisely know where deallocation is used, use AdaControl (for any solution). If you want to be confident that there is no direct deallocation in a module, the generic wins.

It loses because you can have direct, immediate deallocation without the "with Ada.Unchecked_Deallocation" somewhere in the context clause.

pack.ads:

with Ada.Unchecked_Deallocation;
package Pack is
type IA is access Integer;
procedure Release is new Ada.Unchecked_Deallocation (Integer, IA);
end;

----
proc.adb:

with Pack;
procedure Proc is
use Pack;
P : IA;
begin
P := new Integer;
Release (P);
end;

what J-P. Rosen meant was that P'Free could be in the body of
Pack.Release, and then it would not be in Proc either.


perso i like the design with the "generic".
(I'm used to it anyway, although of course it's worse than not needing
explicit Deallocation.)

but the question is: why in the specification ???


actually i need to know more about your case:

- do you find it ok to put the access types in the package
specification, and then not have control over what they become?

- or don't you want that, but you regularly become in situations where
you have no choice (for example because you need components of which you
are not the author)?


what's your opinion about String_Access and Free in
Ada.Strings.Unbounded?

I don't understand what they are doing here, since this package is made
to avoid needing them...

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-04-16 05:44, Thomas wrote:

In article <s5h0o5$1piu$[email protected]>,
"Dmitry A. Kazakov" <[email protected]> wrote:

On 2021-04-18 11:09, Jeffrey R. Carter wrote:

On 4/18/21 10:46 AM, Gautier write-only address wrote:

Side note: did anyone already suggest a new keyword: unchecked_free
and a special statement:

   unchecked_free Some_Pointer;

For every access variable P, there could exist the attribute procedure

  P'Free;

I like the idea of attaching it to a variable rather than to type.

why?

Because operations apply to objects not to
the types of.

if it had to be made, i would say it could not be less than sth like: T'Unchecked_Free (P)

This does as little sense as T'Image did.

I remember the claim that originally making it a generic procedure with
an indigestible name was meant as barrier for lazy programmers.

not only that:
i agree J-P. Rosen (he didn't said exactly that),
it's fine to be able to search for the "Unchecked" keyword, to look at
parts of code with some known risk (afaik):
Ada.Unchecked_Deallocation, Ada.Unchecked_Conversion, Unchecked_Access.

You can search for "Free" as easily.

Furthermore, the way unchecked stuff breaks the program is such that the
actual problem is almost never located at the place where you call
something unchecked. The error is usually triggered in a different place.

Plus
some considerations regarding garbage collection lurked in the subconscious.

could you explain, please ? :-)

You allocate objects at will and the language per magic wand frees them
for you someway someday. This anything that works in a non-magical way
(read: deterministic, predictable, explicit) is so outrageous that must
be highlighted as "unchecked." (:-))

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <s5vpul$ldb$[email protected]>,
"Randy Brukardt" <[email protected]> wrote:

"Niklas Holsti" <[email protected]d> wrote in message news:[email protected]...

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/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <s5naeu$r4c$[email protected]>,
"Dmitry A. Kazakov" <[email protected]> wrote:

On 2021-04-20 20:53, Randy Brukardt wrote:

OTOH, an Ada
follow-on would most likely have access types with automatic deallocation as
proposed by Tucker in one of the many AIs on ownership.

who is Tucker, and where can i read him, please? :-)

So using any form of
explicit deallocation would be discouraged (as would the use of raw pointer types).

I do not understand how that could work, it sounds like a halting
problem to me,

i feel that:

1)
afaik, non-pool-specific access-to-variable types, which should point on aliased objects, are not dangerous, as long as neither new nor Unchecked_Deallocation are used.

2)
pool-specific access-to-variable types should mostly look like Ada.Containers.Indefinite_Holders.
there is missing one for definite limited types,
and i hope it's possible to also make it for indefinite limited types
(if it's not allowed in Ada, it should be planned for an Ada follow-on).

but anyway, where is a problem? Add a whole new hierarchy
of access types independent on the existing one.

anyway, we can begin to think about it, and see later what it should
become.
but if Tucker already begun to think about it, i would prefer read him
before develop my own think, to avoid redo what he already did :-)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-04-18 8:51, Thomas wrote:

In article <s5naeu$r4c$[email protected]>,
"Dmitry A. Kazakov" <[email protected]> wrote:

On 2021-04-20 20:53, Randy Brukardt wrote:

OTOH, an Ada
follow-on would most likely have access types with automatic deallocation as
proposed by Tucker in one of the many AIs on ownership.

who is Tucker, and where can i read him, please? :-)

He is Tucker Taft, one of the designers and maintainers of the Ada language.

An "AI" is an "Ada Issue", an entry in discussions about Ada features
and the Ada standard. The AIs are collected in a public, searchable
database at http://www.ada-auth.org/ais.html.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)