* Unchecked_Deallocation with tagged types @ 1996-11-22 0:00 Paul Burnim 1996-11-23 0:00 ` Simon Wright 0 siblings, 1 reply; 49+ 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] 49+ messages in thread
* Re: Unchecked_Deallocation with tagged types 1996-11-22 0:00 Unchecked_Deallocation with tagged types Paul Burnim @ 1996-11-23 0:00 ` Simon Wright 0 siblings, 0 replies; 49+ 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] 49+ 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; 49+ 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] 49+ messages in thread
* Re: Unchecked_Deallocation with tagged types 2021-04-17 21:45 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ messages in thread
* Re: 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 2021-04-18 8:46 ` Gautier write-only address 2021-04-18 9:13 ` DrPi 1 sibling, 2 replies; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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 ` Stephen Leake 0 siblings, 2 replies; 49+ 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] 49+ 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 ` Stephen Leake 1 sibling, 1 reply; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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; 49+ 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] 49+ 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 4 siblings, 0 replies; 49+ 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] 49+ 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; 49+ 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] 49+ messages in thread
* Re: Unchecked_Deallocation with tagged types 2021-04-22 8:55 ` Stephen Leake @ 2021-04-22 11:16 ` Jeffrey R. Carter 2021-04-22 15:49 ` Vincent Marciante 0 siblings, 1 reply; 49+ 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] 49+ 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; 49+ 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] 49+ messages in thread
end of thread, other threads:[~2022-04-18 6:26 UTC | newest] Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-11-22 0:00 Unchecked_Deallocation with tagged types Paul Burnim 1996-11-23 0:00 ` Simon Wright -- strict thread matches above, loose matches on Subject: below -- 2021-04-17 21:45 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 2021-04-22 8:55 ` Stephen Leake 2021-04-22 11:16 ` Jeffrey R. Carter 2021-04-22 15:49 ` Vincent Marciante
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox