* USE clauses @ 1986-08-06 2:08 "David S. Bakin" 1986-08-07 1:09 ` alden%jade 0 siblings, 1 reply; 9+ messages in thread From: "David S. Bakin" @ 1986-08-06 2:08 UTC (permalink / raw) OK, this is just to let you know that the mail is piling up around here on my question on use-clauses, with the current sentiment being not to use them at all. I'll summarize next week, but in the meantime, anyone who sends me mail saying not to use use-clauses at all please include a description of how you access user-defined operators. Not how you should, how you actually do. By the way, I don't buy the arguments about code with use-clauses being harder to read. 1) You should be using an interactive tool to help you understand your code (more about this in a later message, if anyone jumps at the bait) 2) I find it harder to read code that stretches across the page and down across pages because of full qualification. Anyway, keep those cards and letters coming, folks! (For those of you who DO use use-clauses, please let me know how your compiler fares with them! At least one compiler spec sheet that I've seen says it "processes withed packages at several thousand lines per minute" which of course implies that it takes time to scan withed packages instead of just having direct access in a library. Does anyone use a compiler whose time-to-compile grows based on the size of the withed and/or used context? And if so, how does it affect your programming style?) -- Dave (Bakin -at mit-multics) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: USE clauses 1986-08-06 2:08 USE clauses "David S. Bakin" @ 1986-08-07 1:09 ` alden%jade 0 siblings, 0 replies; 9+ messages in thread From: alden%jade @ 1986-08-07 1:09 UTC (permalink / raw) David, You can access operators with prefix notation and dot (.) notation with the package name. my_var := my_package."+"(op1,op2); Also, the arguement for using use based on long names is still weak. If you have a problem with long package names then use RENAMES, again as local to the block affected as possible. Renames can be used to abrivate the package name or to abreviate the package and operation combination. The arguement for tools to analyze code is a good one. To date, the only good tool to do this kind of analysis is on the Rational R1000 computer. Have you got $750,000.00 to give me so that I can use the tool? ... Tony Alden TRW ^ permalink raw reply [flat|nested] 9+ messages in thread
* Unchecked_Deallocation with tagged types @ 2021-04-17 21:45 DrPi 2021-04-18 8:21 ` Dmitry A. Kazakov 0 siblings, 1 reply; 9+ 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] 9+ messages in thread
* Re: Unchecked_Deallocation with tagged types 2021-04-17 21:45 Unchecked_Deallocation with tagged types DrPi @ 2021-04-18 8:21 ` Dmitry A. Kazakov 2021-04-18 9:13 ` DrPi 0 siblings, 1 reply; 9+ 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] 9+ messages in thread
* Re: Unchecked_Deallocation with tagged types 2021-04-18 8:21 ` Dmitry A. Kazakov @ 2021-04-18 9:13 ` DrPi 2021-04-18 16:48 ` Jeffrey R. Carter 0 siblings, 1 reply; 9+ 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] 9+ messages in thread
* Re: Unchecked_Deallocation with tagged types 2021-04-18 9:13 ` DrPi @ 2021-04-18 16:48 ` Jeffrey R. Carter 2021-04-20 15:57 ` Stephen Leake 0 siblings, 1 reply; 9+ 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] 9+ 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; 9+ 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] 9+ 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 0 siblings, 1 reply; 9+ 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] 9+ 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 0 siblings, 1 reply; 9+ 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] 9+ 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; 9+ 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] 9+ 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-24 1:04 ` Randy Brukardt 0 siblings, 1 reply; 9+ 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] 9+ messages in thread
* Re: Unchecked_Deallocation with tagged types 2021-04-21 10:21 ` Vincent Marciante @ 2021-04-24 1:04 ` Randy Brukardt 2022-04-12 23:25 ` use clauses Thomas 0 siblings, 1 reply; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ messages in thread
* Re: use clauses 2022-04-19 3:53 ` Thomas @ 2022-04-19 5:59 ` Randy Brukardt 0 siblings, 0 replies; 9+ 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] 9+ messages in thread
end of thread, other threads:[~2022-04-19 5:59 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1986-08-06 2:08 USE clauses "David S. Bakin" 1986-08-07 1:09 ` alden%jade -- strict thread matches above, loose matches on Subject: below -- 2021-04-17 21:45 Unchecked_Deallocation with tagged types DrPi 2021-04-18 8:21 ` Dmitry A. Kazakov 2021-04-18 9:13 ` 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-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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox