comp.lang.ada
 help / color / mirror / Atom feed
* Unchecked_Deallocation with tagged types
@ 1996-11-22  0:00 Paul Burnim
  1996-11-23  0:00 ` Simon Wright
  0 siblings, 1 reply; 56+ messages in thread
From: Paul Burnim @ 1996-11-22  0:00 UTC (permalink / raw)



Hi,

I'm using my own garbage collection routine for some dynamically
allocated objects, e.g.

    type anytype;

    type anytype_ptr is access all anytype'Class;

    type anytype is tagged record
        .....
    end record;

    type r_integer is new anytype with record
        val : integer;
    end record;

my question is, if I create an unchecked_deallocation for the type
anytype, will it correctly deallocate an object of the type r_integer,
or do I need to explicitly call an unchecked_deallocation for r_integer.

e.g.

        procedure Free is new
            Unchecked_Deallocation (anytype, anytype_ptr);

     a : anytype_ptr
    begin
     a := new r_integer'(val => 1, ...)
     Free(a);
    end;

Thanks


Paul.
--
  _-_|\  Paul Burnim                                  EMAIL: paulb@cs.uq.edu.au
 /     * Computer Science Department      RM 614 - PH:3365 1181 - FAX:3365 1999
 \_.-._/ The University of Queensland                  http://www.hotdiscs.com/
      v  Australia 4072                   Home of the Kylie & SAW Mailing Lists




^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  1996-11-22  0:00 Paul Burnim
@ 1996-11-23  0:00 ` Simon Wright
  0 siblings, 0 replies; 56+ messages in thread
From: Simon Wright @ 1996-11-23  0:00 UTC (permalink / raw)



paulb@cs.uq.edu.au (Paul Burnim) writes:

> I'm using my own garbage collection routine for some dynamically
> allocated objects, e.g.
> 
>     type anytype;
> 
>     type anytype_ptr is access all anytype'Class;
> 
>     type anytype is tagged record
>         .....
>     end record;
> 
>     type r_integer is new anytype with record
>         val : integer;
>     end record;
> 
> my question is, if I create an unchecked_deallocation for the type
> anytype, will it correctly deallocate an object of the type r_integer,
> or do I need to explicitly call an unchecked_deallocation for r_integer.
> 
> e.g.
> 
>         procedure Free is new
>             Unchecked_Deallocation (anytype, anytype_ptr);
> 
>      a : anytype_ptr
>     begin
>      a := new r_integer'(val => 1, ...)
>      Free(a);
>     end;

I asked a very similar question yesterday, which hadn't made it onto
the Net by this morning. I'd checked the Rationale, FAQ, Barnes,
Feldman .. finally check John English's book (Ada 95, the craft of
object-oriented programming, ISBN 0-13-230350-7) and there's the
answer on page [.. I went straight to it in the bookshop; now where
.. ah!] 298. My version is

package T is
  type X is abstract tagged null record;
  type Xp is access X'Class;
  procedure Deallocate (The_Xp : in out Xp);
end T;

with Unchecked_Deallocation;
package body T is
  procedure Free is new Unchecked_Deallocation (X'Class, Xp);
  procedure Deallocate (The_Xp : in out Xp) renames Free;
end T;

-- 
Simon Wright                    Work Email: simon.j.wright@gecm.com
Ferranti Naval Systems                     Voice: +44(0)1705-701778
GEC-Marconi S3I Combat Systems Division      FAX: +44(0)1705-701800




^ permalink raw reply	[flat|nested] 56+ messages in thread

* Unchecked_Deallocation with tagged types
@ 2021-04-17 21:45 DrPi
  2021-04-17 22:29 ` Rod Kay
  2021-04-18  8:21 ` Dmitry A. Kazakov
  0 siblings, 2 replies; 56+ messages in thread
From: DrPi @ 2021-04-17 21:45 UTC (permalink / raw)


Hi,

I have the following types :

    type t_Element_Record is tagged null record;
    type t_Element is access all t_Element_Record'Class;

    type t_Str_Record (Str_Length : Natural) is new t_Element_Record 
with record
       Str : String (1 .. Str_Length);
    end record;
    type t_Str is access all t_Str_Record'Class;

Do I have to create a Unchecked_Deallocation procedure for each tagged 
type or only one for the root tagged type (and the compiler manages the 
effective tagged type) ?

Nicolas

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-17 21:45 Unchecked_Deallocation with tagged types DrPi
@ 2021-04-17 22:29 ` Rod Kay
  2021-04-17 22:36   ` Rod Kay
  2021-04-18  8:21 ` Dmitry A. Kazakov
  1 sibling, 1 reply; 56+ messages in thread
From: Rod Kay @ 2021-04-17 22:29 UTC (permalink / raw)


I believe it is ...

    procedure free is new Ada.unchecked_Deallocation (t_Element, 
t_Element_Record'Class);


Regards.

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-17 22:29 ` Rod Kay
@ 2021-04-17 22:36   ` Rod Kay
  2021-04-18  9:06     ` DrPi
  2021-04-18  9:07     ` Jeffrey R. Carter
  0 siblings, 2 replies; 56+ messages in thread
From: Rod Kay @ 2021-04-17 22:36 UTC (permalink / raw)


On 18/4/21 8:29 am, Rod Kay wrote:
> I believe it is ...
> 
>    procedure free is new Ada.unchecked_Deallocation (t_Element, 
> t_Element_Record'Class);
> 
> 
> Regards.


Ugh ... I mean ...

    procedure free is new Ada.unchecked_Deallocation 
(t_Element_Record'Class, t_Element);


Sorry, early morning brain fog :).

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-17 21:45 Unchecked_Deallocation with tagged types DrPi
  2021-04-17 22:29 ` Rod Kay
@ 2021-04-18  8:21 ` Dmitry A. Kazakov
  2021-04-18  8:46   ` Gautier write-only address
  2021-04-18  9:13   ` DrPi
  1 sibling, 2 replies; 56+ messages in thread
From: Dmitry A. Kazakov @ 2021-04-18  8:21 UTC (permalink / raw)


On 2021-04-17 23:45, DrPi wrote:

> I have the following types :
> 
>    type t_Element_Record is tagged null record;
>    type t_Element is access all t_Element_Record'Class;
> 
>    type t_Str_Record (Str_Length : Natural) is new t_Element_Record with 
> record
>       Str : String (1 .. Str_Length);
>    end record;
>    type t_Str is access all t_Str_Record'Class;
> 
> Do I have to create a Unchecked_Deallocation procedure for each tagged 
> type or only one for the root tagged type (and the compiler manages the 
> effective tagged type) ?

You have Unchecked_Deallocation for the type you deallocate. In your 
case the answer is neither. You instantiate Unchecked_Deallocation for 
the class.

    procedure Free is
       new Ada.Unchecked_Deallocation
           (  t_Element_Record'Class,
              t_Element
           );

P.S. Hungarian notation is evil. Using suffixes on top of Hungarian 
notation is evil squared.

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

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18  8:21 ` Dmitry A. Kazakov
@ 2021-04-18  8:46   ` Gautier write-only address
  2021-04-18  9:09     ` Jeffrey R. Carter
  2021-04-18  9:13   ` DrPi
  1 sibling, 1 reply; 56+ messages in thread
From: Gautier write-only address @ 2021-04-18  8:46 UTC (permalink / raw)


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

  unchecked_free Some_Pointer;

?

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-17 22:36   ` Rod Kay
@ 2021-04-18  9:06     ` DrPi
  2021-04-18  9:07     ` Jeffrey R. Carter
  1 sibling, 0 replies; 56+ messages in thread
From: DrPi @ 2021-04-18  9:06 UTC (permalink / raw)


Le 18/04/2021 à 00:36, Rod Kay a écrit :
> On 18/4/21 8:29 am, Rod Kay wrote:
>> I believe it is ...
>>
>>    procedure free is new Ada.unchecked_Deallocation (t_Element, 
>> t_Element_Record'Class);
>>
>>
>> Regards.
> 
> 
> Ugh ... I mean ...
> 
>    procedure free is new Ada.unchecked_Deallocation 
> (t_Element_Record'Class, t_Element);
> 
> 
> Sorry, early morning brain fog :).
This wouldn't happen to me ;)

Thanks

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-17 22:36   ` Rod Kay
  2021-04-18  9:06     ` DrPi
@ 2021-04-18  9:07     ` Jeffrey R. Carter
  1 sibling, 0 replies; 56+ messages in thread
From: Jeffrey R. Carter @ 2021-04-18  9:07 UTC (permalink / raw)


On 4/18/21 12:36 AM, Rod Kay wrote:
> On 18/4/21 8:29 am, Rod Kay wrote:
>> I believe it is ...
>>
>>    procedure free is new Ada.unchecked_Deallocation (t_Element, 
>> t_Element_Record'Class);
> 
> Ugh ... I mean ...
> 
>     procedure free is new Ada.unchecked_Deallocation (t_Element_Record'Class, 
> t_Element);

No, you mean

    ... new Ada.Unchecked_Deallocation
               (Object => Name_Repeating_2_Things_From_The_Code'Class,
                Name   => Name_Repeating_1_Thing_From_The_Code);

which ensures that you don't make a mistake when you write it, and understand 
what is what when you read it (although Pointer would be better than Name).

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18  8:46   ` Gautier write-only address
@ 2021-04-18  9:09     ` Jeffrey R. Carter
  2021-04-18 10:13       ` Dmitry A. Kazakov
  2021-04-18 10:20       ` J-P. Rosen
  0 siblings, 2 replies; 56+ messages in thread
From: Jeffrey R. Carter @ 2021-04-18  9:09 UTC (permalink / raw)


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;

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18  8:21 ` Dmitry A. Kazakov
  2021-04-18  8:46   ` Gautier write-only address
@ 2021-04-18  9:13   ` DrPi
  2021-04-18 10:01     ` Dmitry A. Kazakov
  2021-04-18 16:48     ` Jeffrey R. Carter
  1 sibling, 2 replies; 56+ messages in thread
From: DrPi @ 2021-04-18  9:13 UTC (permalink / raw)


Le 18/04/2021 à 10:21, Dmitry A. Kazakov a écrit :
> On 2021-04-17 23:45, DrPi wrote:
> 
>> I have the following types :
>>
>>    type t_Element_Record is tagged null record;
>>    type t_Element is access all t_Element_Record'Class;
>>
>>    type t_Str_Record (Str_Length : Natural) is new t_Element_Record 
>> with record
>>       Str : String (1 .. Str_Length);
>>    end record;
>>    type t_Str is access all t_Str_Record'Class;
>>
>> Do I have to create a Unchecked_Deallocation procedure for each tagged 
>> type or only one for the root tagged type (and the compiler manages 
>> the effective tagged type) ?
> 
> You have Unchecked_Deallocation for the type you deallocate. In your 
> case the answer is neither. You instantiate Unchecked_Deallocation for 
> the class.
> 
>    procedure Free is
>       new Ada.Unchecked_Deallocation
>           (  t_Element_Record'Class,
>              t_Element
>           );
> 
Thanks

> P.S. Hungarian notation is evil. Using suffixes on top of Hungarian 
> notation is evil squared.
> 
I know Ada convention is to use Camel_Case_Syntax. Maybe there's also a 
convention for naming ?

What's the convention you use for naming ?

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18  9:13   ` DrPi
@ 2021-04-18 10:01     ` Dmitry A. Kazakov
  2021-04-18 10:42       ` DrPi
  2021-04-18 16:48     ` Jeffrey R. Carter
  1 sibling, 1 reply; 56+ messages in thread
From: Dmitry A. Kazakov @ 2021-04-18 10:01 UTC (permalink / raw)


On 2021-04-18 11:13, DrPi wrote:

> I know Ada convention is to use Camel_Case_Syntax. Maybe there's also a 
> convention for naming ?
> 
> What's the convention you use for naming ?

If you use suffixes, then stick to them.

    Element_Record / Element

The above is GtkAda convention. GtkAda object types have the suffix 
_Record, because they are used rarely. The access to object types have 
no suffix, because they are used most.

The normal case is rather reverse, e.g.

    Element / Element_Ptr

Because access types are infrequent.

The Ada standard library tend to use _Type, e.g. File_Type, for types. 
It works well when you have very general concepts, like 
Root_Stream_Type, you want to stick out.

In a specific application program you would rather avoid _Type and 
choose something descriptive, like Customer_Report. Then an instance of 
could be more vague, like Report.

So, no convention, I would say, just common sense.

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

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18  9:09     ` Jeffrey R. Carter
@ 2021-04-18 10:13       ` Dmitry A. Kazakov
  2022-04-16  3:44         ` Thomas
  2021-04-18 10:20       ` J-P. Rosen
  1 sibling, 1 reply; 56+ messages in thread
From: Dmitry A. Kazakov @ 2021-04-18 10:13 UTC (permalink / raw)


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.

-------------
I remember the claim that originally making it a generic procedure with 
an indigestible name was meant as barrier for lazy programmers. Plus 
some considerations regarding garbage collection lurked in the subconscious.

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

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18  9:09     ` Jeffrey R. Carter
  2021-04-18 10:13       ` Dmitry A. Kazakov
@ 2021-04-18 10:20       ` J-P. Rosen
  2021-04-18 10:34         ` Dmitry A. Kazakov
  2021-04-18 16:08         ` Jeffrey R. Carter
  1 sibling, 2 replies; 56+ messages in thread
From: J-P. Rosen @ 2021-04-18 10:20 UTC (permalink / raw)


Le 18/04/2021 à 11:09, Jeffrey R. Carter a écrit :
> 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;
> 
Which would defeat the goal of Unchecked_Deallocation.

Ada (or more precisely Ichbiah) chose to deallocate through an 
instantiation of a generic for good reason. Deallocation is a place 
where many problems can come from, it is important to be able to trace 
where they are. The current solution forces you to put "with 
Unchecked_Deallocation" on top of every module that deallocates, 
therefore telling the reader that there is some danger in it, and making 
it easier to find where all the deallocations happen.

Now, I know that in those days, ease of writing is considered more 
important than ease of reading and long term maintenance...

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18 10:20       ` J-P. Rosen
@ 2021-04-18 10:34         ` Dmitry A. Kazakov
  2021-04-18 15:14           ` J-P. Rosen
  2021-04-18 16:08         ` Jeffrey R. Carter
  1 sibling, 1 reply; 56+ messages in thread
From: Dmitry A. Kazakov @ 2021-04-18 10:34 UTC (permalink / raw)


On 2021-04-18 12:20, J-P. Rosen wrote:
> Le 18/04/2021 à 11:09, Jeffrey R. Carter a écrit :
>> 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;
>>
> Which would defeat the goal of Unchecked_Deallocation.
> 
> Ada (or more precisely Ichbiah) chose to deallocate through an 
> instantiation of a generic for good reason. Deallocation is a place 
> where many problems can come from, it is important to be able to trace 
> where they are. The current solution forces you to put "with 
> Unchecked_Deallocation" on top of every module that deallocates, 
> therefore telling the reader that there is some danger in it, and making 
> it easier to find where all the deallocations happen.

No, that does not work. If we supposed to search for all calls to 
deallocate, then attribute 'Free is much easier to look after than first 
looking for "with Unchecked_Deallocation", then for an instantiation of 
it with the types in question and then for the name of the instance.

> Now, I know that in those days, ease of writing is considered more 
> important than ease of reading and long term maintenance...

Yes, but dangling pointers is a more complex problem, that effortlessly 
passes brief code inspections. I agree with you in general, but disagree 
in this case. *IF* pointers are used *THEN* Unchecked_Deallocation only 
obfuscates things rather than helps.

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

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18 10:01     ` Dmitry A. Kazakov
@ 2021-04-18 10:42       ` DrPi
  0 siblings, 0 replies; 56+ messages in thread
From: DrPi @ 2021-04-18 10:42 UTC (permalink / raw)


Le 18/04/2021 à 12:01, Dmitry A. Kazakov a écrit :
> On 2021-04-18 11:13, DrPi wrote:
> 
>> I know Ada convention is to use Camel_Case_Syntax. Maybe there's also 
>> a convention for naming ?
>>
>> What's the convention you use for naming ?
> 
> If you use suffixes, then stick to them.
> 
>    Element_Record / Element
> 
> The above is GtkAda convention. GtkAda object types have the suffix 
> _Record, because they are used rarely. The access to object types have 
> no suffix, because they are used most.
> 
> The normal case is rather reverse, e.g.
> 
>    Element / Element_Ptr
> 
> Because access types are infrequent.
> 
> The Ada standard library tend to use _Type, e.g. File_Type, for types. 
> It works well when you have very general concepts, like 
> Root_Stream_Type, you want to stick out.
> 
> In a specific application program you would rather avoid _Type and 
> choose something descriptive, like Customer_Report. Then an instance of 
> could be more vague, like Report.
> 
> So, no convention, I would say, just common sense.
> 
And one common sense per programmer ;)

Thanks

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18 10:34         ` Dmitry A. Kazakov
@ 2021-04-18 15:14           ` J-P. Rosen
  2021-04-18 15:23             ` Gautier write-only address
  0 siblings, 1 reply; 56+ messages in thread
From: J-P. Rosen @ 2021-04-18 15:14 UTC (permalink / raw)


Le 18/04/2021 à 12:34, Dmitry A. Kazakov a écrit :
>> Ada (or more precisely Ichbiah) chose to deallocate through an 
>> instantiation of a generic for good reason. Deallocation is a place 
>> where many problems can come from, it is important to be able to trace 
>> where they are. The current solution forces you to put "with 
>> Unchecked_Deallocation" on top of every module that deallocates, 
>> therefore telling the reader that there is some danger in it, and 
>> making it easier to find where all the deallocations happen.
> 
> No, that does not work. If we supposed to search for all calls to 
> deallocate, then attribute 'Free is much easier to look after than first 
> looking for "with Unchecked_Deallocation", then for an instantiation of 
> it with the types in question and then for the name of the instance.

I meant it the other way round: if the module has no "with 
unchecked_deallocation", you know it does not deallocate anything, 
without looking at the entire body.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18 15:14           ` J-P. Rosen
@ 2021-04-18 15:23             ` Gautier write-only address
  2021-04-18 15:53               ` J-P. Rosen
  2021-04-20 18:53               ` Randy Brukardt
  0 siblings, 2 replies; 56+ messages in thread
From: Gautier write-only address @ 2021-04-18 15:23 UTC (permalink / raw)


Le dimanche 18 avril 2021 à 17:14:13 UTC+2, J-P. Rosen a écrit :

> I meant it the other way round: if the module has no "with 
> unchecked_deallocation", you know it does not deallocate anything, 
> without looking at the entire body.

Not at all: the instantiation can be defined of in another package - and it is often the case - with any name (Free, Dispose, ...).
So actually with the present way it is difficult to track where unchecked deallocation is used, plus it is tedious for the programmers.
The P'Free  atttribute or the "unchecked_free P;" statement would be straightforward to track.

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18 15:23             ` Gautier write-only address
@ 2021-04-18 15:53               ` J-P. Rosen
  2021-04-18 16:08                 ` Gautier write-only address
  2021-04-20 18:53               ` Randy Brukardt
  1 sibling, 1 reply; 56+ messages in thread
From: J-P. Rosen @ 2021-04-18 15:53 UTC (permalink / raw)


Le 18/04/2021 à 17:23, Gautier write-only address a écrit :
> Le dimanche 18 avril 2021 à 17:14:13 UTC+2, J-P. Rosen a écrit :
> 
>> I meant it the other way round: if the module has no "with
>> unchecked_deallocation", you know it does not deallocate anything,
>> without looking at the entire body.
> 
> Not at all: the instantiation can be defined of in another package - and it is often the case - with any name (Free, Dispose, ...).
> So actually with the present way it is difficult to track where unchecked deallocation is used, plus it is tedious for the programmers.
> The P'Free  atttribute or the "unchecked_free P;" statement would be straightforward to track.
> 
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.

And after all, the attribute only saves you one line of code... (OK, two 
if you count the "with" ;-) )

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18 10:20       ` J-P. Rosen
  2021-04-18 10:34         ` Dmitry A. Kazakov
@ 2021-04-18 16:08         ` Jeffrey R. Carter
  1 sibling, 0 replies; 56+ messages in thread
From: Jeffrey R. Carter @ 2021-04-18 16:08 UTC (permalink / raw)


On 4/18/21 12:20 PM, J-P. Rosen wrote:
>>
>> For every access variable P, there could exist the attribute procedure
>>
>>    P'Free;
>>
> Which would defeat the goal of Unchecked_Deallocation.
> 
> Ada (or more precisely Ichbiah) chose to deallocate through an instantiation of 
> a generic for good reason. Deallocation is a place where many problems can come 
> from, it is important to be able to trace where they are. The current solution 
> forces you to put "with Unchecked_Deallocation" on top of every module that 
> deallocates, therefore telling the reader that there is some danger in it, and 
> making it easier to find where all the deallocations happen.

Since all Ada developers only use access types when necessary (0.1% of programs) 
and always hide them in packages, this is less of an issue.

In the ideal world.

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18 15:53               ` J-P. Rosen
@ 2021-04-18 16:08                 ` Gautier write-only address
  2022-04-16  5:00                   ` Thomas
  0 siblings, 1 reply; 56+ messages in thread
From: Gautier write-only address @ 2021-04-18 16:08 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18  9:13   ` DrPi
  2021-04-18 10:01     ` Dmitry A. Kazakov
@ 2021-04-18 16:48     ` Jeffrey R. Carter
  2021-04-20 15:57       ` Stephen Leake
  1 sibling, 1 reply; 56+ messages in thread
From: Jeffrey R. Carter @ 2021-04-18 16:48 UTC (permalink / raw)


On 4/18/21 11:13 AM, DrPi wrote:
>>
> I know Ada convention is to use Camel_Case_Syntax. Maybe there's also a 
> convention for naming ?

There are many conventions for naming, most of them poor (defined as any I don't 
like).

You know the rule that comments should not repeat what's clear from the code? A 
similar rule should apply to identifiers. So if you have

type <Name> is record ...

it's clear that <Name> is a type name for a record type, so it should not repeat 
any of that.

Many types are declared in package specs, along with operations on the type. 
There, the objective should be to have parameter names for the operations that 
read well with named notation. The type name must then be something different. I 
like to use

package Lists is
    type Handle is tagged limited private;

    procedure Clear (List : in out Handle);

and then use

    List : Lists.Handle;

    List.Clear;

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18 16:48     ` Jeffrey R. Carter
@ 2021-04-20 15:57       ` Stephen Leake
  2021-04-20 17:24         ` Jeffrey R. Carter
  0 siblings, 1 reply; 56+ messages in thread
From: Stephen Leake @ 2021-04-20 15:57 UTC (permalink / raw)


"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:

> package Lists is
>    type Handle is tagged limited private;
>
>    procedure Clear (List : in out Handle);
>
> and then use
>
>    List : Lists.Handle;
>
>    List.Clear;

Just to provide an alternative, I like:

 package Lists is
    type List is tagged limited private;

    procedure Clear (List : in out Lists.List);

 and then use

    List : Lists.List;

    List.Clear;


that saves you having to think up a bogus name for the 'list' type.

-- 
-- Stephe

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-20 15:57       ` Stephen Leake
@ 2021-04-20 17:24         ` Jeffrey R. Carter
  2021-04-20 17:34           ` Vincent Marciante
  2021-04-22  8:55           ` Unchecked_Deallocation with tagged types Stephen Leake
  0 siblings, 2 replies; 56+ messages in thread
From: Jeffrey R. Carter @ 2021-04-20 17:24 UTC (permalink / raw)


On 4/20/21 5:57 PM, Stephen Leake wrote:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> 
>> package Lists is
>>     type Handle is tagged limited private;
>>
>>     procedure Clear (List : in out Handle);
>>
>> and then use
>>
>>     List : Lists.Handle;
>>
>>     List.Clear;
> 
> Just to provide an alternative, I like:
> 
>   package Lists is
>      type List is tagged limited private;
> 
>      procedure Clear (List : in out Lists.List);
> 
>   and then use
> 
>      List : Lists.List;
> 
>      List.Clear;

Lists.List is a bit repetitive. Are you sure you don't want 
Lists.Listy_List_Listing?

> that saves you having to think up a bogus name for the 'list' type.

I think of private types as allowing you to manipulate their abstraction without 
know how it's implemented, much as the handle on a suitcase allows you to 
manipulate its contents without knowing what's in there. So Handle seems an 
appropriate name.

-- 
Jeff Carter
"I'm particularly glad that these lovely children were
here today to hear that speech. Not only was it authentic
frontier gibberish, it expressed a courage little seen
in this day and age."
Blazing Saddles
88

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-20 17:24         ` Jeffrey R. Carter
@ 2021-04-20 17:34           ` Vincent Marciante
  2021-04-20 20:56             ` Jeffrey R. Carter
  2021-04-22  8:55           ` Unchecked_Deallocation with tagged types Stephen Leake
  1 sibling, 1 reply; 56+ messages in thread
From: Vincent Marciante @ 2021-04-20 17:34 UTC (permalink / raw)


On Tuesday, April 20, 2021 at 1:24:08 PM UTC-4, Jeffrey R. Carter wrote:
> On 4/20/21 5:57 PM, Stephen Leake wrote: 
> > "Jeffrey R. Carter" wrote: 
> > 
> >> package Lists is 
> >> type Handle is tagged limited private; 
> >> 
> >> procedure Clear (List : in out Handle); 
> >> 
> >> and then use 
> >> 
> >> List : Lists.Handle; 
> >> 
> >> List.Clear; 
> > 
> > Just to provide an alternative, I like: 
> > 
> > package Lists is 
> > type List is tagged limited private; 
> > 
> > procedure Clear (List : in out Lists.List); 
> > 
> > and then use 
> > 
> > List : Lists.List; 
> > 
> > List.Clear;
> Lists.List is a bit repetitive. Are you sure you don't want 
> Lists.Listy_List_Listing?
> > that saves you having to think up a bogus name for the 'list' type.
> I think of private types as allowing you to manipulate their abstraction without 
> know how it's implemented, much as the handle on a suitcase allows you to 
> manipulate its contents without knowing what's in there. So Handle seems an 
> appropriate name. 
> 
> -- 
> Jeff Carter 
> "I'm particularly glad that these lovely children were 
> here today to hear that speech. Not only was it authentic 
> frontier gibberish, it expressed a courage little seen 
> in this day and age." 
> Blazing Saddles 
> 88

As people might remember from long ago, I'm in the

    Lists.List

 camp.

 (Wouldn't some "C" people argue for using the same name but
different capitalization to disambiguate ?:-)

[Vin runs away]

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18 15:23             ` Gautier write-only address
  2021-04-18 15:53               ` J-P. Rosen
@ 2021-04-20 18:53               ` Randy Brukardt
  2021-04-20 19:35                 ` Dmitry A. Kazakov
  2021-04-20 20:32                 ` Jeffrey R. Carter
  1 sibling, 2 replies; 56+ messages in thread
From: Randy Brukardt @ 2021-04-20 18:53 UTC (permalink / raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

Only if you enforced a Restriction (No_Unchecked_Deallocation_Instances)! 
Otherwise, you have two mechanisms to do the same thing, which is even less 
easy to track. And of course, you couldn't usefully do that in existing Ada 
code (of which there is a lot).

'Free makes more sense in a new language (an Ada follow-on). 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. So using any form of 
explicit deallocation would be discouraged (as would the use of raw pointer 
types).

                        Randy.

"Gautier write-only address" <gautier_niouzes@hotmail.com> wrote in message 
news:3d6e49b6-f195-4dc2-bf4b-795f18f2da9dn@googlegroups.com...
Le dimanche 18 avril 2021 à 17:14:13 UTC+2, J-P. Rosen a écrit :

> I meant it the other way round: if the module has no "with
> unchecked_deallocation", you know it does not deallocate anything,
> without looking at the entire body.

Not at all: the instantiation can be defined of in another package - and it 
is often the case - with any name (Free, Dispose, ...).
So actually with the present way it is difficult to track where unchecked 
deallocation is used, plus it is tedious for the programmers.
The P'Free  atttribute or the "unchecked_free P;" statement would be 
straightforward to track. 


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-20 18:53               ` Randy Brukardt
@ 2021-04-20 19:35                 ` Dmitry A. Kazakov
  2022-04-18  5:51                   ` Thomas
  2021-04-20 20:32                 ` Jeffrey R. Carter
  1 sibling, 1 reply; 56+ messages in thread
From: Dmitry A. Kazakov @ 2021-04-20 19:35 UTC (permalink / raw)


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. 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, but anyway, where is a problem? Add a whole new hierarchy 
of access types independent on the existing one.

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

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-20 18:53               ` Randy Brukardt
  2021-04-20 19:35                 ` Dmitry A. Kazakov
@ 2021-04-20 20:32                 ` Jeffrey R. Carter
  2021-04-20 21:10                   ` Niklas Holsti
  1 sibling, 1 reply; 56+ messages in thread
From: Jeffrey R. Carter @ 2021-04-20 20:32 UTC (permalink / raw)


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.

-- 
Jeff Carter
"I'm particularly glad that these lovely children were
here today to hear that speech. Not only was it authentic
frontier gibberish, it expressed a courage little seen
in this day and age."
Blazing Saddles
88

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-20 17:34           ` Vincent Marciante
@ 2021-04-20 20:56             ` Jeffrey R. Carter
  2021-04-21 10:21               ` Vincent Marciante
  0 siblings, 1 reply; 56+ messages in thread
From: Jeffrey R. Carter @ 2021-04-20 20:56 UTC (permalink / raw)


On 4/20/21 7:34 PM, Vincent Marciante wrote:
> 
>      Lists.List

My objection is that this says the same thing twice (hence my joke about adding 
more variants of "List" to it). "This is a list, and by the way, this is a 
list." To me, Lists.Handle says, "This is something that lets you manipulate a 
hidden implementation of lists."

But the most important thing, I think, is that you've thought about naming and 
can give meaningful reasoning for your choice. Too often the reason for wanting 
to use the same name for everything is, "I don't want to think." But thinking of 
good names is an important part of S/W engineering.

>   (Wouldn't some "C" people argue for using the same name but
> different capitalization to disambiguate ?:-)

You can literally use the same name for almost everything in Ada:

package List is
    type List is tagged limited private;

    procedure Clear (List: in out Standard.List.List);

List : Standard.List.List;

List.Clear;

Even worse, in some cases you can use Latin, Greek, and Cyrillic letters with 
very similar glyphs to disambiguate.

-- 
Jeff Carter
"I'm particularly glad that these lovely children were
here today to hear that speech. Not only was it authentic
frontier gibberish, it expressed a courage little seen
in this day and age."
Blazing Saddles
88

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-20 20:32                 ` Jeffrey R. Carter
@ 2021-04-20 21:10                   ` Niklas Holsti
  2021-04-21  8:35                     ` Jeffrey R. Carter
  2021-04-24  0:49                     ` Randy Brukardt
  0 siblings, 2 replies; 56+ messages in thread
From: Niklas Holsti @ 2021-04-20 21:10 UTC (permalink / raw)


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.

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-20 21:10                   ` Niklas Holsti
@ 2021-04-21  8:35                     ` Jeffrey R. Carter
  2021-04-21 10:11                       ` Dmitry A. Kazakov
  2021-04-24  0:49                     ` Randy Brukardt
  1 sibling, 1 reply; 56+ messages in thread
From: Jeffrey R. Carter @ 2021-04-21  8:35 UTC (permalink / raw)


On 4/20/21 11:10 PM, Niklas Holsti wrote:
> 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 don't see that pointers are needed for such S/W.

Brukardt has recently been discussing the idea that a high-level language such 
as Ada should not have arrays, which is why I referenced it. Such a language 
might not be convenient for such systems.

But the idea is that arrays are a low-level implementation feature that are 
usually used to implement higher-level abstractions, such as sequences and maps. 
A language without arrays would have direct support for such abstractions. My 
experience is that most uses of arrays in embedded, real-time S/W are also for 
such abstractions, so it would probably not be too great a problem.

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail
09

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-21  8:35                     ` Jeffrey R. Carter
@ 2021-04-21 10:11                       ` Dmitry A. Kazakov
  0 siblings, 0 replies; 56+ messages in thread
From: Dmitry A. Kazakov @ 2021-04-21 10:11 UTC (permalink / raw)


On 2021-04-21 10:35, Jeffrey R. Carter wrote:
> On 4/20/21 11:10 PM, Niklas Holsti wrote:
>> 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 don't see that pointers are needed for such S/W.

Try to load and bind a relocatable library without pointers.

> Brukardt has recently been discussing the idea that a high-level 
> language such as Ada should not have arrays, which is why I referenced 
> it. Such a language might not be convenient for such systems.
> 
> But the idea is that arrays are a low-level implementation feature that 
> are usually used to implement higher-level abstractions, such as 
> sequences and maps. A language without arrays would have direct support 
> for such abstractions.

That is not enough, even if providing such abstractions were viable. 
Which is not, because they would be far more complex than array 
abstraction and resolve none of the problems array abstraction has. E.g. 
container subtypes constrained to subtypes of elements and/or subtypes 
of keys.

Array is a simplest case of container. If you cannot handle arrays, how 
do you hope to handle maps?

Then see above, and explain how an opaque map will deal with a shared 
memory mapped into the process address space? Or what would be the 
primitive operation Write of Root_Stream_Type?

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

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-20 20:56             ` Jeffrey R. Carter
@ 2021-04-21 10:21               ` Vincent Marciante
  2021-04-21 10:28                 ` Vincent Marciante
                                   ` (4 more replies)
  0 siblings, 5 replies; 56+ messages in thread
From: Vincent Marciante @ 2021-04-21 10:21 UTC (permalink / raw)


On Tuesday, April 20, 2021 at 4:57:00 PM UTC-4, Jeffrey R. Carter wrote:
> On 4/20/21 7:34 PM, Vincent Marciante wrote: 
> > 
> > Lists.List 
> 
> My objection is that this says the same thing twice (hence my joke about adding 
> more variants of "List" to it). "This is a list, and by the way, this is a 
> list." To me, Lists.Handle says, "This is something that lets you manipulate a 
> hidden implementation of lists." 
> 
> But the most important thing, I think, is that you've thought about naming ...

But that idiom pretty much prohibits "using" more than one package with such naming:

use Queues, Lists; 

Queue : Handle; --\  Both
List : Handle;     --/ ambiguous

vs.

Command_Queue : Queue;
Parameter_List : List;

I guess the issue is similar the past discussions on idiomatically naming 
all tagged types Object.

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-21 10:21               ` Vincent Marciante
@ 2021-04-21 10:28                 ` Vincent Marciante
  2021-04-21 12:13                 ` Simon Wright
                                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 56+ messages in thread
From: Vincent Marciante @ 2021-04-21 10:28 UTC (permalink / raw)


On Wednesday, April 21, 2021 at 6:21:57 AM UTC-4, Vincent Marciante wrote:
> On Tuesday, April 20, 2021 at 4:57:00 PM UTC-4, Jeffrey R. Carter wrote: 
> > On 4/20/21 7:34 PM, Vincent Marciante wrote: 
> > > 
> > > Lists.List 
> > 
> > My objection is that this says the same thing twice (hence my joke about adding 
> > more variants of "List" to it). "This is a list, and by the way, this is a 
> > list." To me, Lists.Handle says, "This is something that lets you manipulate a 
> > hidden implementation of lists." 
> >
> > But the most important thing, I think, is that you've thought about naming ... 
> 
> But that idiom pretty much prohibits "using" more than one package with such naming: 
> 
> use Queues, Lists; 
> 
> Queue : Handle; --\ Both 
> List : Handle; --/ ambiguous 
> 
> vs. 
> 
> Command_Queue : Queue; 
> Parameter_List : List; 
> 
> I guess the issue is similar the past discussions on idiomatically naming 
> all tagged types Object.

Ha!   Guess one would just write:



 Queue :Queues. Handle  List :Lists. HandleUltimately, unless something is just too wordy it is just a matter of personal taste:

Queue : Pack_Queues_Package.T_Queue_Handle_Type: --Bad! 

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-21 10:21               ` Vincent Marciante
  2021-04-21 10:28                 ` Vincent Marciante
@ 2021-04-21 12:13                 ` Simon Wright
  2021-04-21 13:28                 ` J-P. Rosen
                                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 56+ messages in thread
From: Simon Wright @ 2021-04-21 12:13 UTC (permalink / raw)


Vincent Marciante <vincent.marciante@l3harris.com> writes:

> But that idiom pretty much prohibits "using" more than one package
> with such naming:
>
> use Queues, Lists; 
>
> Queue : Handle;    --\  Both
> List : Handle;     --/ ambiguous

A good thing, too.

Anyway, you can still say "Queue : Queues.Handle;".

And Queue probably isn't a very good name for the object.

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-21 10:21               ` Vincent Marciante
  2021-04-21 10:28                 ` Vincent Marciante
  2021-04-21 12:13                 ` Simon Wright
@ 2021-04-21 13:28                 ` J-P. Rosen
  2021-04-22 10:21                   ` Vincent Marciante
  2021-04-21 13:42                 ` Jeffrey R. Carter
  2021-04-24  1:04                 ` Randy Brukardt
  4 siblings, 1 reply; 56+ messages in thread
From: J-P. Rosen @ 2021-04-21 13:28 UTC (permalink / raw)


Le 21/04/2021 à 12:21, Vincent Marciante a écrit :
> But that idiom pretty much prohibits "using" more than one package with such naming:
> 
> use Queues, Lists;
> 
> Queue : Handle; --\  Both
> List : Handle;     --/ ambiguous
> 
I would not agree with "prohibits". You may still use qualified notation 
in the scope of a "use" clause, so yes, you have to write:
Queue : Queues.Handle;
List : Lists.Handle;

which is not worse that having:
Queue : Queues_Handle;
List : Lists_Handle;

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-21 10:21               ` Vincent Marciante
                                   ` (2 preceding siblings ...)
  2021-04-21 13:28                 ` J-P. Rosen
@ 2021-04-21 13:42                 ` Jeffrey R. Carter
  2021-04-24  1:04                 ` Randy Brukardt
  4 siblings, 0 replies; 56+ messages in thread
From: Jeffrey R. Carter @ 2021-04-21 13:42 UTC (permalink / raw)


On 4/21/21 12:21 PM, Vincent Marciante wrote:
> On Tuesday, April 20, 2021 at 4:57:00 PM UTC-4, Jeffrey R. Carter wrote:
>> On 4/20/21 7:34 PM, Vincent Marciante wrote:
>>>
>>> Lists.List
>>
>> My objection is that this says the same thing twice (hence my joke about adding
>> more variants of "List" to it). "This is a list, and by the way, this is a
>> list." To me, Lists.Handle says, "This is something that lets you manipulate a
>> hidden implementation of lists."
>>
>> But the most important thing, I think, is that you've thought about naming ...
> 
> But that idiom pretty much prohibits "using" more than one package with such naming:
> 
> use Queues, Lists;
> 
> Queue : Handle; --\  Both
> List : Handle;     --/ ambiguous

Yes. But you can't use your preferred naming (pkg Lists, type List) either:

Queue : Queue; -- Both
List  : List;  -- illegal

Unless you give the pkg name, too, which you can do in either case.

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail
09

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-20 17:24         ` Jeffrey R. Carter
  2021-04-20 17:34           ` Vincent Marciante
@ 2021-04-22  8:55           ` Stephen Leake
  2021-04-22 11:16             ` Jeffrey R. Carter
  1 sibling, 1 reply; 56+ messages in thread
From: Stephen Leake @ 2021-04-22  8:55 UTC (permalink / raw)


"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:

> On 4/20/21 5:57 PM, Stephen Leake wrote:
>> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
>> 
>>> package Lists is
>>>     type Handle is tagged limited private;
>>>
>>>     procedure Clear (List : in out Handle);
>>>
>>> and then use
>>>
>>>     List : Lists.Handle;
>>>
>>>     List.Clear;
>> Just to provide an alternative, I like:
>>   package Lists is
>>      type List is tagged limited private;
>>      procedure Clear (List : in out Lists.List);
>>   and then use
>>      List : Lists.List;
>>      List.Clear;
>
> Lists.List is a bit repetitive. Are you sure you don't want
> Lists.Listy_List_Listing?

Yes. It's a list. Just a list, nothing more, nothing less.

>
>
>> that saves you having to think up a bogus name for the 'list' type.
>
> I think of private types as allowing you to manipulate their
> abstraction without know how it's implemented, much as the handle on a
> suitcase allows you to manipulate its contents without knowing what's
> in there. So Handle seems an appropriate name.

In this case, the point of the package is precisely to provide a list,
implemented by an actual list. It's not a "bag" or some other "generic
container". That would be a at higher level, where the type would be
"bag" or "generic_container".

-- 
-- Stephe

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-21 13:28                 ` J-P. Rosen
@ 2021-04-22 10:21                   ` Vincent Marciante
  0 siblings, 0 replies; 56+ messages in thread
From: Vincent Marciante @ 2021-04-22 10:21 UTC (permalink / raw)


On Wednesday, April 21, 2021 at 9:28:06 AM UTC-4, J-P. Rosen wrote:
> Le 21/04/2021 à 12:21, Vincent Marciante a écrit : 
> > But that idiom pretty much prohibits "using" more than one package with such naming: 
> > 
> > use Queues, Lists; 
> > 
> > Queue : Handle; --\ Both 
> > List : Handle; --/ ambiguous 
> >
> I would not agree with "prohibits". You may still use qualified notation 
> in the scope of a "use" clause, so yes, you have to write: 
> Queue : Queues.Handle; 
> List : Lists.Handle; 
> 
> which is not worse that having: 
> Queue : Queues_Handle; 
> List : Lists_Handle;
> -- 
> J-P. Rosen 
> Adalog 
> 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX 
> Tel: +33 1 45 29 21 52
> https://www.adalog.fr
Of course you are correct (my last response seems to have been garbled by Google groups).
But - in the case the there is only one such type involved, I'd prefer

X : List; Y : List; instead of X : Handle; Y : Handle;

I do not like the idea/idiom that the type always has the same name - handle - and 
"thingness" is only expressed by the package name.  _That_ seems way more redundant
and is a redundancy that cannot be removed by a "use" clause, whereas, the redundancy 
in something like  Guests : Lists.List; can be made to be Guests : List and still express
the nature of the data structure.

But like I wrote in my garbled response, I think that it ultimately become an issue of
individual preference. (Not talking about what might be the decree/agreement in the 
guidelines/standard of a multi-person project.) 


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-22  8:55           ` Unchecked_Deallocation with tagged types Stephen Leake
@ 2021-04-22 11:16             ` Jeffrey R. Carter
  2021-04-22 15:49               ` Vincent Marciante
  0 siblings, 1 reply; 56+ messages in thread
From: Jeffrey R. Carter @ 2021-04-22 11:16 UTC (permalink / raw)


On 4/22/21 10:55 AM, Stephen Leake wrote:
> 
> In this case, the point of the package is precisely to provide a list,

The purpose of the package is to provide lists, not a single list.

> implemented by an actual list. It's not a "bag" or some other "generic
> container". That would be a at higher level, where the type would be
> "bag" or "generic_container".

Yes, that's why it's a List's Handle (Lists.Handle), something that lets you 
manipulate a list without knowing how it's implemented.

-- 
Jeff Carter
"Why, the Mayflower was full of Fireflies, and a few
horseflies, too. The Fireflies were on the upper deck,
and the horseflies were on the Fireflies."
Duck Soup
95

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-22 11:16             ` Jeffrey R. Carter
@ 2021-04-22 15:49               ` Vincent Marciante
  0 siblings, 0 replies; 56+ messages in thread
From: Vincent Marciante @ 2021-04-22 15:49 UTC (permalink / raw)


On Thursday, April 22, 2021 at 7:16:54 AM UTC-4, Jeffrey R. Carter wrote:
> Yes, that's why it's a List's Handle (Lists.Handle), something that lets you 
> manipulate a list without knowing how it's implemented. 

(Only somewhat tongue-in-cheek )
That seems to imply that any type that is somewhat complicated 
would be named handle and most of the important types in large
systems are somewhat complicated types and therefore all of the
important types would be named handle.  In source code names,
the difference between a "_" character and a "." character is not
that much, so this style is similar to having to tack "_type" at the
end of all type names:  List.Handle and List_Type are both distasteful
to me when all I'd need is List to indicate the nature of the type!

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-20 21:10                   ` Niklas Holsti
  2021-04-21  8:35                     ` Jeffrey R. Carter
@ 2021-04-24  0:49                     ` Randy Brukardt
  2022-04-18  1:51                       ` Thomas
  1 sibling, 1 reply; 56+ messages in thread
From: Randy Brukardt @ 2021-04-24  0:49 UTC (permalink / raw)


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

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

                           Randy.


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-21 10:21               ` Vincent Marciante
                                   ` (3 preceding siblings ...)
  2021-04-21 13:42                 ` Jeffrey R. Carter
@ 2021-04-24  1:04                 ` Randy Brukardt
  2022-04-12 23:25                   ` use clauses Thomas
  4 siblings, 1 reply; 56+ messages in thread
From: Randy Brukardt @ 2021-04-24  1:04 UTC (permalink / raw)


"Vincent Marciante" <vincent.marciante@l3harris.com> wrote in message 
news:4205785c-6818-4e26-b931-5a775e2c426cn@googlegroups.com...
> On Tuesday, April 20, 2021 at 4:57:00 PM UTC-4, Jeffrey R. Carter wrote:
>> On 4/20/21 7:34 PM, Vincent Marciante wrote:
>> >
>> > Lists.List
>>
>> My objection is that this says the same thing twice (hence my joke about 
>> adding
>> more variants of "List" to it). "This is a list, and by the way, this is 
>> a
>> list." To me, Lists.Handle says, "This is something that lets you 
>> manipulate a
>> hidden implementation of lists."
>>
>> But the most important thing, I think, is that you've thought about 
>> naming ...
>
> But that idiom pretty much prohibits "using" more than one package with 
> such naming:

Yes, of course, that's a feature, not a bug. ;-)

One of the things that I learned when building Claw is that there is no 
naming convention that works well for use clauses and for the use-adverse. 
We ended up with a scheme that sort of works for both (using _Type) but it 
ideal for neither. I'd guess that most authors fall into one or the other 
camps and pick a scheme accordingly.

For me, a naming scheme that discourages the use of (package) use clauses is 
a bonus. (Such a scheme makes it easier to avoid use clauses.) I personally 
only use "use type" in new code (there's tons of old code for which that 
doesn't work, of course, but that doesn't change the principle).

                                    Randy.


^ permalink raw reply	[flat|nested] 56+ messages in thread

* use clauses
  2021-04-24  1:04                 ` Randy Brukardt
@ 2022-04-12 23:25                   ` Thomas
  2022-04-13  1:05                     ` Randy Brukardt
  0 siblings, 1 reply; 56+ messages in thread
From: Thomas @ 2022-04-12 23:25 UTC (permalink / raw)


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

> For me, a naming scheme that discourages the use of (package) use clauses is 
> a bonus. (Such a scheme makes it easier to avoid use clauses.)

I agree to avoid use clauses.

(I personally prefer Lists.List, like Vincent Marciante -
i like Ada.Containers.* naming :-) )


> I personally 
> only use "use type" in new code (there's tons of old code for which that 
> doesn't work, of course, but that doesn't change the principle).

what do you think about:
- "use all type" clauses?
- List.Clear? (could you remember me how you call that, please?)
- List.Clear does work only if List is tagged?

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

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: use clauses
  2022-04-12 23:25                   ` use clauses Thomas
@ 2022-04-13  1:05                     ` Randy Brukardt
  2022-04-14  2:51                       ` 25.BX944
  2022-04-19  3:53                       ` Thomas
  0 siblings, 2 replies; 56+ messages in thread
From: Randy Brukardt @ 2022-04-13  1:05 UTC (permalink / raw)


"Thomas" <fantome.forums.tDeContes@free.fr.invalid> wrote in message 
news:62560a6b$0$18724$426a74cc@news.free.fr...
> In article <s5vqq9$lou$1@franka.jacob-sparre.dk>,
> "Randy Brukardt" <randy@rrsoftware.com> wrote:
>
>> For me, a naming scheme that discourages the use of (package) use clauses 
>> is
>> a bonus. (Such a scheme makes it easier to avoid use clauses.)
>
> I agree to avoid use clauses.
>
> (I personally prefer Lists.List, like Vincent Marciante -
> i like Ada.Containers.* naming :-) )
>
>
>> I personally
>> only use "use type" in new code (there's tons of old code for which that
>> doesn't work, of course, but that doesn't change the principle).
>
> what do you think about:
> - "use all type" clauses?

This is OK; I don't use them mainly because I only use features implemented 
in Janus/Ada, and "use all type" is not yet implemented there.

The fundamental problem with "use" is that it makes everything visible, and 
then deals with conflicts by making those things invisible again. That's not 
problem for overloadable primitive operations, since the profile is included 
and conflicts only occur when someone has made a lousy design choice 
(creating a routine with the same name and profile as a primitive) [Most 
such conflicts come from maintenance when some existing routine is moved to 
be primitive; in such cases, the original routine simply should be removed.] 
Since "use all type" only works on overloadable primitives (and things that 
work rather like primitives), it's fairly safe. One could make an argument 
that primitive operations should always be visible when the type is (that's 
not the Ada rule, but argubly it would work better in most circumstances) --  
and you should always know to look at primitives anyway when trying to find 
something..

> - List.Clear? (could you remember me how you call that, please?)

For tagged types, you can use prefix notation, so "My_List.Clear" is the 
easiest. With "use all type List", you can write Clear(My_List). If your 
objects have well-choosen names, it's not really needed to have the type 
around for such operations, even when use clauses are in place. Thus, 
"Clear", not "Clear_List", and that works well even when someone uses 
everything in sight (of course, they may have a hard time finding where 
Clear is defined when debugging, but that's their choice).

> - List.Clear does work only if List is tagged?

Right. There are a number of semantic issues for untagged types, the main 
ones having to do with implicit dereference (which occurs in this notation, 
as in any other selected_component notation). If you have a prefix of an 
access type, it gets very messy to determine which dereference is which. And 
just allowing composite types doesn't work well either: a private type that 
is completed with an access type would *lose* operations when it had full 
visibility -- that seems pretty weird.

It originally got limited to tagged types as that was easy to do and didn't 
have semantic issues. We were going to look at generalizing the prefix 
notation again (several people asked about it), but no one made a concrete 
proposal and it never went anywhere for Ada 2022.

                         Randy.


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: use clauses
  2022-04-13  1:05                     ` Randy Brukardt
@ 2022-04-14  2:51                       ` 25.BX944
  2022-04-14  6:49                         ` Emmanuel Briot
  2022-04-15  5:33                         ` Doctor Who
  2022-04-19  3:53                       ` Thomas
  1 sibling, 2 replies; 56+ messages in thread
From: 25.BX944 @ 2022-04-14  2:51 UTC (permalink / raw)


After fiddling around with ADA for awhile, I have concluded
that it's Just Not Worth It - too fiddly, TOO obsessed with
exact types and such. While there are SOME few justifications
for that, well, it's just pretty much UNUSABLE. If I need to
use an "old" language, well, FORTRAN is easier to deal with
and I actually *like* Pascal (I write lots of stuff in
Lazarus/FPC even today). And, of course, 'C' ...

So, unless you are somehow OBLIGATED, use something,
anything, but ADA.

Sorry, not what you wanted to hear, but ......

I will now de-subscribe.

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: use clauses
  2022-04-14  2:51                       ` 25.BX944
@ 2022-04-14  6:49                         ` Emmanuel Briot
  2022-04-15  5:33                         ` Doctor Who
  1 sibling, 0 replies; 56+ messages in thread
From: Emmanuel Briot @ 2022-04-14  6:49 UTC (permalink / raw)


On Thursday, April 14, 2022 at 4:51:10 AM UTC+2, 25.BX944 wrote:
> So, unless you are somehow OBLIGATED, use something, 
> anything, but ADA. 

I fully understand. Can I recommend that you try Whitespace (https://en.wikipedia.org/wiki/Whitespace_(programming_language)) or Basic as your language of choice ? They should not be as bothersome as Ada. Of course, the surprises come at run time !

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: use clauses
  2022-04-14  2:51                       ` 25.BX944
  2022-04-14  6:49                         ` Emmanuel Briot
@ 2022-04-15  5:33                         ` Doctor Who
  1 sibling, 0 replies; 56+ messages in thread
From: Doctor Who @ 2022-04-15  5:33 UTC (permalink / raw)


On Wed, 13 Apr 2022 22:51:01 -0400, "25.BX944" <25BZ494@nada.net>
wrote:

>After fiddling around with ADA for awhile, I have concluded
>that it's Just Not Worth It - too fiddly, TOO obsessed with
>exact types and such. While there are SOME few justifications
>for that, well, it's just pretty much UNUSABLE. If I need to
>use an "old" language, well, FORTRAN is easier to deal with
>and I actually *like* Pascal (I write lots of stuff in
>Lazarus/FPC even today). And, of course, 'C' ...
>
>So, unless you are somehow OBLIGATED, use something,
>anything, but ADA.
>
>Sorry, not what you wanted to hear, but ......
>
>I will now de-subscribe.

you are not a programmer.

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18 10:13       ` Dmitry A. Kazakov
@ 2022-04-16  3:44         ` Thomas
  2022-04-16  8:09           ` Dmitry A. Kazakov
  0 siblings, 1 reply; 56+ messages in thread
From: Thomas @ 2022-04-16  3:44 UTC (permalink / raw)


In article <s5h0o5$1piu$1@gioia.aioe.org>,
 "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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/

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-18 16:08                 ` Gautier write-only address
@ 2022-04-16  5:00                   ` Thomas
  0 siblings, 0 replies; 56+ messages in thread
From: Thomas @ 2022-04-16  5:00 UTC (permalink / raw)


In article <b37bc687-b72f-4bc4-858c-77dc9b878cffn@googlegroups.com>,
 Gautier write-only address <gautier_niouzes@hotmail.com> 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/

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2022-04-16  3:44         ` Thomas
@ 2022-04-16  8:09           ` Dmitry A. Kazakov
  0 siblings, 0 replies; 56+ messages in thread
From: Dmitry A. Kazakov @ 2022-04-16  8:09 UTC (permalink / raw)


On 2022-04-16 05:44, Thomas wrote:
> In article <s5h0o5$1piu$1@gioia.aioe.org>,
>   "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-24  0:49                     ` Randy Brukardt
@ 2022-04-18  1:51                       ` Thomas
  0 siblings, 0 replies; 56+ messages in thread
From: Thomas @ 2022-04-18  1:51 UTC (permalink / raw)


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/

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2021-04-20 19:35                 ` Dmitry A. Kazakov
@ 2022-04-18  5:51                   ` Thomas
  2022-04-18  6:26                     ` Niklas Holsti
  0 siblings, 1 reply; 56+ messages in thread
From: Thomas @ 2022-04-18  5:51 UTC (permalink / raw)


In article <s5naeu$r4c$1@gioia.aioe.org>,
 "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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/

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Unchecked_Deallocation with tagged types
  2022-04-18  5:51                   ` Thomas
@ 2022-04-18  6:26                     ` Niklas Holsti
  0 siblings, 0 replies; 56+ messages in thread
From: Niklas Holsti @ 2022-04-18  6:26 UTC (permalink / raw)


On 2022-04-18 8:51, Thomas wrote:
> In article <s5naeu$r4c$1@gioia.aioe.org>,
>   "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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.

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: use clauses
  2022-04-13  1:05                     ` Randy Brukardt
  2022-04-14  2:51                       ` 25.BX944
@ 2022-04-19  3:53                       ` Thomas
  2022-04-19  5:59                         ` Randy Brukardt
  1 sibling, 1 reply; 56+ messages in thread
From: Thomas @ 2022-04-19  3:53 UTC (permalink / raw)


In article <t357jt$v7n$1@dont-email.me>,
 "Randy Brukardt" <randy@rrsoftware.com> wrote:

> "Thomas" <fantome.forums.tDeContes@free.fr.invalid> wrote in message 
> news:62560a6b$0$18724$426a74cc@news.free.fr...
> > In article <s5vqq9$lou$1@franka.jacob-sparre.dk>,
> > "Randy Brukardt" <randy@rrsoftware.com> wrote:
> >
> >> I personally
> >> only use "use type" in new code (there's tons of old code for which that
> >> doesn't work, of course, but that doesn't change the principle).
> >
> > what do you think about:
> > - "use all type" clauses?
> 
> This is OK; I don't use them mainly because I only use features implemented 
> in Janus/Ada, and "use all type" is not yet implemented there.
> 
> The fundamental problem with "use" is that it makes everything visible, and 
> then deals with conflicts by making those things invisible again.


> Since "use all type" only works on overloadable primitives (and things that 
> work rather like primitives), it's fairly safe. One could make an argument 
> that primitive operations should always be visible when the type is (that's 
> not the Ada rule, but argubly it would work better in most circumstances) --  
> and you should always know to look at primitives anyway when trying to find 
> something..

are you speaking about a case like Ada.Text_IO.Unbounded_IO?
i would say that these subprograms are not primitives, since they are 
not declared in the same package,
and i don't see in which case we could get a type visible but not its 
primitives.

in this case, the best thing to do that i found is:
   use all type Ada.Text_IO.File_Type;
   use Ada.Text_IO.Unbounded_IO;
is there sth best?


BTW, i often get a repetition in the same declare bloc, like:
   File       : Ada.Text_IO.File_Type;
   use all type Ada.Text_IO.File_Type;

what do you think about generate an automatic "use all type" where the 
variable is declared?


> 
> > - List.Clear? (could you remember me how you call that, please?)
> 
> For tagged types, you can use prefix notation, so "My_List.Clear" is the 
> easiest. With "use all type List", you can write Clear(My_List).

i asked for your opinion, because J-P. Rosen told me he doesn't like 
that. so i would like to know main usages, practicals, ...

if i got it, you use prefix notation a lot, because you have no access 
to "use all type"?


> ["Clear" works well even when someone uses 
> everything in sight] (of course, they may have a hard time finding where 
> Clear is defined when debugging, but that's their choice).

are you sure?
i would say either there is only 1 Clear for the type List, and if it's 
a primitive it's easy to know where to find it, or there are many Clear 
for the type List, and they are not visibles.


> 
> > - List.Clear does work only if List is tagged?
> 
> Right. There are a number of semantic issues for untagged types, the main 
> ones having to do with implicit dereference (which occurs in this notation, 
> as in any other selected_component notation). If you have a prefix of an 
> access type, it gets very messy to determine which dereference is which. And 
> just allowing composite types doesn't work well either: a private type that 
> is completed with an access type would *lose* operations when it had full 
> visibility -- that seems pretty weird.
> 
> It originally got limited to tagged types as that was easy to do and didn't 
> have semantic issues.

what's i don't understand is, there is sth which work better with tagged 
types than with untagged types, whereas tagged types are known to be 
more complex to give special functionnality, not to be simpler to use.

could you give me a concrete example please, of a case where using 
prefix notation with an untagged type causes a particular problem, and 
then making the type tagged permits to resolve the problem?


> We were going to look at generalizing the prefix 
> notation again (several people asked about it), but no one made a concrete 
> proposal and it never went anywhere for Ada 2022.

(maybe i could make one if i understand enough? :-) )

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

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: use clauses
  2022-04-19  3:53                       ` Thomas
@ 2022-04-19  5:59                         ` Randy Brukardt
  0 siblings, 0 replies; 56+ messages in thread
From: Randy Brukardt @ 2022-04-19  5:59 UTC (permalink / raw)


"Thomas" <fantome.forums.tDeContes@free.fr.invalid> wrote in message 
news:625e324c$0$18369$426a34cc@news.free.fr...
> In article <t357jt$v7n$1@dont-email.me>,
> "Randy Brukardt" <randy@rrsoftware.com> wrote:
>
>> "Thomas" <fantome.forums.tDeContes@free.fr.invalid> wrote in message
>> news:62560a6b$0$18724$426a74cc@news.free.fr...
>> > In article <s5vqq9$lou$1@franka.jacob-sparre.dk>,
>> > "Randy Brukardt" <randy@rrsoftware.com> wrote:
>> >
>> >> I personally
>> >> only use "use type" in new code (there's tons of old code for which 
>> >> that
>> >> doesn't work, of course, but that doesn't change the principle).
>> >
>> > what do you think about:
>> > - "use all type" clauses?
>>
>> This is OK; I don't use them mainly because I only use features 
>> implemented
>> in Janus/Ada, and "use all type" is not yet implemented there.
>>
>> The fundamental problem with "use" is that it makes everything visible, 
>> and
>> then deals with conflicts by making those things invisible again.
>
>
>> Since "use all type" only works on overloadable primitives (and things 
>> that
>> work rather like primitives), it's fairly safe. One could make an 
>> argument
>> that primitive operations should always be visible when the type is 
>> (that's
>> not the Ada rule, but argubly it would work better in most 
>> circumstances) --
>> and you should always know to look at primitives anyway when trying to 
>> find
>> something..
>
> are you speaking about a case like Ada.Text_IO.Unbounded_IO?

No, I was thinking more about typical ADTs (abstract data types), which 
usually come with most of their operations in a package. The containers, 
Text_IO, and Claw are all examples. Operations in packages like this are the 
ones that "use all type" make visible, and that's OK because that's where 
you would look for operations on the type anyway.

> i would say that these subprograms are not primitives, since they are
> not declared in the same package,

Correct.

> and i don't see in which case we could get a type visible but not its
> primitives.

The primitives and type are visible, but not directly visible (I hate that 
terminology). Which means you can use them with full names, but not 
directly. For types, I almost always use the full name anyway (since they 
aren't referenced that much). So if you have an object:

     Fyle : Ada.Text_IO.File_Type;

the type is visible (but not directly visible). It's annoying that you have 
to jump thru hoops (such as "use all type") in order to get them. Operators 
in particular should always work so long as the type is visible (even if not 
directly visible). But that would require restricting where they are 
declared, and it's too late to do that for Ada.

> in this case, the best thing to do that i found is:
>   use all type Ada.Text_IO.File_Type;
>   use Ada.Text_IO.Unbounded_IO;
> is there sth best?

I just write out such things.

    Ada.Text_IO.Unbounded_IO.Put (My_String);

If I had to use a lot of them in some code, I'd probably use a local rename. 
It's not great, but at least you can figure out where the thing is declared 
without having some giant IDE running all the time..

> BTW, i often get a repetition in the same declare bloc, like:
>   File       : Ada.Text_IO.File_Type;
>   use all type Ada.Text_IO.File_Type;

Yup.

> what do you think about generate an automatic "use all type" where the
> variable is declared?

For tagged objects, you already have it effectively with prefix notation. 
And who cares about antique stuff?? :-)

>> > - List.Clear? (could you remember me how you call that, please?)
>>
>> For tagged types, you can use prefix notation, so "My_List.Clear" is the
>> easiest. With "use all type List", you can write Clear(My_List).
>
> i asked for your opinion, because J-P. Rosen told me he doesn't like
> that. so i would like to know main usages, practicals, ...
>
> if i got it, you use prefix notation a lot, because you have no access
> to "use all type"?

Nope: Janus/Ada doesn't implement that yet, either (it was an Ada 2005 
feature). I personally write a lot of long-winded identifiers:

    Foobar (UString => Ada.Strings.Unbounded.To_Unbounded_String 
(My_Package.Data_Selector (Glarch, 3));

(Although that one often gets a special rename:

     function "+" (A : in String) return 
Ada.Strings.Unbounded.Unbounded_String renames
       Ada.Strings.Unbounded.To_Unbounded_String;

and then:

    Foobar (UString => + My_Package.Data_Selector (Glarch, 3));

I'd rather not do that, but this one gets to be too much... :-)

>> ["Clear" works well even when someone uses
>> everything in sight] (of course, they may have a hard time finding where
>> Clear is defined when debugging, but that's their choice).
>
> are you sure?
> i would say either there is only 1 Clear for the type List, and if it's
> a primitive it's easy to know where to find it, or there are many Clear
> for the type List, and they are not visibles.

The usual problem is that they didn't name their objects very well and thus 
don't know the type. Or it's maintenance and you don't know the code well 
enough to know the type. Or it's 40 years later and you've forgotten 
everything you knew about the code (my situation with Janus/Ada code :-). If 
you don't know the type or know where it it declared, it's hard to know 
where to look for primitives. And not all code is organized as ADTs 
(especially true in older code), so there may not be a lot of primitives.

>> > - List.Clear does work only if List is tagged?
>>
>> Right. There are a number of semantic issues for untagged types, the main
>> ones having to do with implicit dereference (which occurs in this 
>> notation,
>> as in any other selected_component notation). If you have a prefix of an
>> access type, it gets very messy to determine which dereference is which. 
>> And
>> just allowing composite types doesn't work well either: a private type 
>> that
>> is completed with an access type would *lose* operations when it had full
>> visibility -- that seems pretty weird.
>>
>> It originally got limited to tagged types as that was easy to do and 
>> didn't
>> have semantic issues.
>
> what's i don't understand is, there is sth which work better with tagged
> types than with untagged types, whereas tagged types are known to be
> more complex to give special functionnality, not to be simpler to use.
>
> could you give me a concrete example please, of a case where using
> prefix notation with an untagged type causes a particular problem, and
> then making the type tagged permits to resolve the problem?

Go read the AIs, I would have to do that to find the details, and I'd 
probably transcribe it wrong. The last discussion was in AI12-0257-1. (I 
looked that up in the AI index - see 
http://www.ada-auth.org/AI12-VOTING.HTML for the Ada 2012 one.)

>> We were going to look at generalizing the prefix
>> notation again (several people asked about it), but no one made a 
>> concrete
>> proposal and it never went anywhere for Ada 2022.
>
> (maybe i could make one if i understand enough? :-) )

That's a big if! :-)

                                Randy.


^ permalink raw reply	[flat|nested] 56+ messages in thread

end of thread, other threads:[~2022-04-19  5:59 UTC | newest]

Thread overview: 56+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-17 21:45 Unchecked_Deallocation with tagged types DrPi
2021-04-17 22:29 ` Rod Kay
2021-04-17 22:36   ` Rod Kay
2021-04-18  9:06     ` DrPi
2021-04-18  9:07     ` Jeffrey R. Carter
2021-04-18  8:21 ` Dmitry A. Kazakov
2021-04-18  8:46   ` Gautier write-only address
2021-04-18  9:09     ` Jeffrey R. Carter
2021-04-18 10:13       ` Dmitry A. Kazakov
2022-04-16  3:44         ` Thomas
2022-04-16  8:09           ` Dmitry A. Kazakov
2021-04-18 10:20       ` J-P. Rosen
2021-04-18 10:34         ` Dmitry A. Kazakov
2021-04-18 15:14           ` J-P. Rosen
2021-04-18 15:23             ` Gautier write-only address
2021-04-18 15:53               ` J-P. Rosen
2021-04-18 16:08                 ` Gautier write-only address
2022-04-16  5:00                   ` Thomas
2021-04-20 18:53               ` Randy Brukardt
2021-04-20 19:35                 ` Dmitry A. Kazakov
2022-04-18  5:51                   ` Thomas
2022-04-18  6:26                     ` Niklas Holsti
2021-04-20 20:32                 ` Jeffrey R. Carter
2021-04-20 21:10                   ` Niklas Holsti
2021-04-21  8:35                     ` Jeffrey R. Carter
2021-04-21 10:11                       ` Dmitry A. Kazakov
2021-04-24  0:49                     ` Randy Brukardt
2022-04-18  1:51                       ` Thomas
2021-04-18 16:08         ` Jeffrey R. Carter
2021-04-18  9:13   ` DrPi
2021-04-18 10:01     ` Dmitry A. Kazakov
2021-04-18 10:42       ` DrPi
2021-04-18 16:48     ` Jeffrey R. Carter
2021-04-20 15:57       ` Stephen Leake
2021-04-20 17:24         ` Jeffrey R. Carter
2021-04-20 17:34           ` Vincent Marciante
2021-04-20 20:56             ` Jeffrey R. Carter
2021-04-21 10:21               ` Vincent Marciante
2021-04-21 10:28                 ` Vincent Marciante
2021-04-21 12:13                 ` Simon Wright
2021-04-21 13:28                 ` J-P. Rosen
2021-04-22 10:21                   ` Vincent Marciante
2021-04-21 13:42                 ` Jeffrey R. Carter
2021-04-24  1:04                 ` Randy Brukardt
2022-04-12 23:25                   ` use clauses Thomas
2022-04-13  1:05                     ` Randy Brukardt
2022-04-14  2:51                       ` 25.BX944
2022-04-14  6:49                         ` Emmanuel Briot
2022-04-15  5:33                         ` Doctor Who
2022-04-19  3:53                       ` Thomas
2022-04-19  5:59                         ` Randy Brukardt
2021-04-22  8:55           ` Unchecked_Deallocation with tagged types Stephen Leake
2021-04-22 11:16             ` Jeffrey R. Carter
2021-04-22 15:49               ` Vincent Marciante
  -- strict thread matches above, loose matches on Subject: below --
1996-11-22  0:00 Paul Burnim
1996-11-23  0:00 ` Simon Wright

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox