!standard 3.02.01(03) 03-09-07 AC95-00078/01 !class amendment 03-09-12 !status received no action 03-09-12 !status received 03-09-09 !subject Proposal for a "with and use" clause !summary !appendix From: Gautier de Montmollin Sent: Tuesday, September 9, 2003 1:11 PM Proposal for a "with and use" clause Hello! Almost the only thing I find tedious in Ada is the obligation to name twice packages you intend to _use_ in a context_clause. I illustrate with examples two usual ways of organizing context clauses: (A) -- (1) With'ed only with Ada.Command_Line; -- (2) With'ed and Use'd with Ada.Text_IO, Ada.Integer_Text_IO, Ada.Float_Text_IO; use Ada.Text_IO, Ada.Integer_Text_IO, Ada.Float_Text_IO; Problem: in practice the list pair (2) is a lot longer (many many lines) and becomes difficult to synchronize. It is also difficult then to _verify_ that the pair is consistent (B) -- (1) With'ed only with Ada.Command_Line; -- (2) With'ed and Use'd with Ada.Text_IO; use Ada.Text_IO; with Ada.Integer_Text_IO; use Ada.Integer_Text_IO; with Ada.Float_Text_IO; use Ada.Float_Text_IO; Advantage: much easier to verify and transport across sources Problem: the beginning of sources becomes awfully long. To sum up, I'd describe the current situation so - beginner-repellent and newcomer-repellent (not to neglect !) - ugly - redundant - causes a readability problem and possible confusions - pushes the real thing, i.e. the programming contents after "procedure/package... is", too far away of the source's top - needs too much administration My proposal: a "with and use" clause. "with and use A[,B]" would mean "with A[,B]; use A[,B]". (C) -- (1) With'ed only with Ada.Command_Line; -- (2) With'ed and Use'd with and use Ada.Text_IO, Ada.Integer_Text_IO, Ada.Float_Text_IO; **************************************************************** From: Mark Lundquist Sent: Tuesday, September 9, 2003 1:23 PM I think I floated something like this out a while back. If not, I meant to do so :-) My only suggestion is a less heavyweight syntax. "with and use" is too COBOL-esque to my eye :-) I'd prefer use with Ada.Text_IO; **************************************************************** From: Nick Roberts Sent: Tuesday, September 9, 2003 5:37 PM It's totally aesthetic, of course, but I rather like "with and use". **************************************************************** From: Gautier de Montmollin Sent: Wednesday, September 10, 2003 4:15 AM I prefer to put "with" before "use" since the package is "with"ed before being "use"d. Maybe "with, use Ada.Text_IO;" as an alternative ? **************************************************************** From: Jeffrey Carter Sent: Wednesday, September 10, 2003 8:26 PM If we're going to do something like, and I'm not convinced it's needed or even desireable, then why not simply say that, in a context clause and ONLY in a context clause, one can write use X; where X has not been mentioned before, and have it equivalent to with X; use X; ? **************************************************************** From: Randy Brukardt Sent: Tuesday, September 9, 2003 10:36 PM > Problem: in practice the list pair (2) is a lot longer (many many > lines) and > becomes difficult to synchronize. It is also difficult then to > _verify_ that the pair is consistent This presumes that the with and use lists ought to be the same. But that is almost never the case. Rarely used packages should never be "use"d, because it adds confusion to the reader. Presuming the program has appropriate (low) coupling, there shouldn't be many packages that need to be "use"d. The rule of localization suggests that in many of the cases where use clauses are needed, they should be placed in local scopes. If Ada 200Y adopts the prefix call notation as an option, the main problem with avoiding use clauses (the difficulty of figuring out the right place for an inherited operation) will go away. So they will be even less necessary than in Ada 95. So this proposal seems to me to be mainly aimed at making a dubious style easier. It's not clear why the language should do that (there are a lot of styles that the language could make easier which seem better supported). **************************************************************** From: Gautier de Montmollin Sent: Wednesday, September 10, 2003 12:18 PM # This presumes that the with and use lists ought to be the same. It doesn't presume it, hence the (1) and (2) lists... # But that is almost never the case. Rarely used packages should never be "use"d, because # it adds confusion to the reader. Presuming the program has appropriate (low) # coupling, there shouldn't be many packages that need to be "use"d. It depends. For instance you can have programs where *many* packages are also *often* used ! A "small" example in my sources: GWindows, GWindows.Application, GWindows.Base, GWindows.Buttons, GWindows.Common_Dialogs, GWindows.Combo_Boxes, GWindows.Constants, GWindows.Cursors, GWindows.Drawing.Capabilities, GWindows.Drawing_Panels, GWindows.Edit_Boxes, GWindows.GStrings, GWindows.Image_Lists, GWindows.Menus, GWindows.Message_Boxes, GWindows.Static_Controls, GWindows.Windows, GWindows.Windows.MDI; In comparison, there are only a couple of "GWindows.*" I prefer to only "with". # The rule of localization suggests that in many of the cases where use # clauses are needed, they should be placed in local scopes. It depends, too. For certain "technical" packages it is more secure and readable to localize the "use" at most, but for a standard package likely to be broadly used (e.g. Ada.Numerics.Long_Elementary_Functions) it would be just a silly noise in the sources. My proposal is for making everyday's programming a bit easier and actually cleaner. I suspect that this small detail plays a non-negligible role in Ada's unpopularity. Just for a small Pascal program with a few maths and I/O the Ada translation needs all that with Ada.Text_IO; use Ada.Text_IO; with Ada.Integer_Text_IO; use Ada.Integer_Text_IO; with Ada.Float_Text_IO; use Ada.Float_Text_IO; with Ada.Direct_IO; with Ada.Numerics; use Ada.Numerics; with Ada.Numerics.Elementary_Functions; use Ada.Numerics.Elementary_Functions; with Ada.Unchecked_Deallocation; ... before the program itself. Of course the reference to these packages themselves is a good thing, but the double naming of 5 of the 7 packages is a useless redundance. # If Ada 200Y adopts the prefix call notation as an option, the main problem # with avoiding use clauses (the difficulty of figuring out the right place # for an inherited operation) will go away. So they will be even less # necessary than in Ada 95. I am not fully "inside" the development - but would it solve the "problem" ? # So this proposal seems to me to be mainly aimed at making a dubious style # easier. It's not clear why the language should do that (there are a lot of # styles that the language could make easier which seem better supported). My point of view: the use_clause as a context_clause is there, it is useful ( :-) ). It forces package names to be written twice, and _that_ is a dubious (forced) style. **************************************************************** From: Randy Brukardt Sent: Wednesday, September 10, 2003 8:09 PM > # This presumes that the with and use lists ought to be the same. > > It doesn't presume it, hence the (1) and (2) lists... My point is that (2) should almost never happen. > # But that is almost never the case. Rarely used packages should never be "use"d, because > # it adds confusion to the reader. Presuming the program has appropriate (low) > # coupling, there shouldn't be many packages that need to be "use"d. > > It depends. For instance you can have programs where *many* packages are > also *often* used ! > A "small" example in my sources: > GWindows, GWindows.Application, GWindows.Base, GWindows.Buttons, > GWindows.Common_Dialogs, GWindows.Combo_Boxes, GWindows.Constants, > GWindows.Cursors, GWindows.Drawing.Capabilities, GWindows.Drawing_Panels, > GWindows.Edit_Boxes, GWindows.GStrings, GWindows.Image_Lists, GWindows.Menus, > GWindows.Message_Boxes, GWindows.Static_Controls, > GWindows.Windows, GWindows.Windows.MDI; > In comparison, there are only a couple of "GWindows.*" I prefer to only > "with". Yikes! You obviously should have used Claw, which was designed to be used without use clauses. :-) But seriously, there is a problem with OOP designs in that figuring out where routines are declared is hard. So people toss in dozens of use clauses in order to avoid needing to do that (which would be needed for fully-qualified calls). I agree that there is a language problem in that case, but the solution isn't to make more forms of use clause! The prefix call notation would avoid the need for the use clauses in the first place: My_Window.Show; does not need a package name nor a use clause. > # The rule of localization suggests that in many of the cases where use > # clauses are needed, they should be placed in local scopes. > > It depends, too. For certain "technical" packages it is more secure and readable > to localize the "use" at most, but for a standard package likely to be broadly used > (e.g. Ada.Numerics.Long_Elementary_Functions) it would be just a silly noise > in the sources. It's rare that a standard package is heavily used enough to justify the use of a use clause. > My proposal is for making everyday's programming a bit easier and actually > cleaner. I suspect that this small detail plays a non-negligible role in Ada's > unpopularity. Just for a small Pascal program with a few maths and I/O the Ada > translation needs all that > > with Ada.Text_IO; use Ada.Text_IO; > with Ada.Integer_Text_IO; use Ada.Integer_Text_IO; > with Ada.Float_Text_IO; use Ada.Float_Text_IO; > with Ada.Direct_IO; > with Ada.Numerics; use Ada.Numerics; > with Ada.Numerics.Elementary_Functions; use Ada.Numerics.Elementary_Functions; > with Ada.Unchecked_Deallocation; > > ... before the program itself. Of course the reference to these packages > themselves is a good thing, but the double naming of 5 of the 7 packages is a useless > redundance. Yikes again! This is precisely the sort of thing that should not happen for a number of reasons. Personally, I almost never "use" Ada.Text_IO; it's short enough to write out. Similarly, I never use the shortcut packages like Ada.Integer_Text_IO, because an instantiation provides both a shorter name and the ability to avoid system-defined types. I wouldn't "use" Ada.Numerics either, because there is almost nothing in it, and I wouldn't even want a very short name like 'e' or 'pi' to be unqualified -- there would be no hope of figuring out where it came from (you can't search on it, that's for sure). Thus, this header would have no use clauses at all if I wrote it (there probably would be a use clause following the instantiation of Generic_Elementary_Functions, but of course that cannot be in the header). ... > # So this proposal seems to me to be mainly aimed at making a dubious style > # easier. It's not clear why the language should do that (there are a lot of > # styles that the language could make easier which seem better supported). > > My point of view: the use_clause as a context_clause is there, it is > useful ( :-) ). It forces package names to be written twice, and _that_ is a > dubious (forced) style. Well, I agree that it is there. But I think the duplicated names is a good thing, because it encourages users to avoid the clause in the first place -- which is certainly a good thing. In any case, even if you like use clauses, you have to admit that this is WAAAYY down on the priority list. This is not a case where something is hard or impossible to do in the current language. So virtually every other proposal (with the possible exception of the one changing the title of Annex H) is more valuable. And this would be reasonably expensive to implement, as it would require changes in not only the syntax but also the data structures used for processing context clauses. As well as changes to the make tool. So this is neither real cheap (like changing the title of Annex H) nor real important -- which means it probably doesn't make the cut. Ada 9x, after all, had a number of good ideas that were left out of the final language simply because they were not important enough. The same will be true with Ada 200Y. **************************************************************** From: Gautier de Montmollin Sent: Saturday, September 13, 2003 4:09 PM [lots of GWindows.*] Randy: # Yikes! You obviously should have used Claw, which was designed to be used # without use clauses. :-) Oh, so next time should I use Claw then ?... Mmmh I would be able to make a large use of the use_clause there too (for Claw.Radio_button, Claw.Push_button, ...). # But seriously, there is a problem with OOP designs in that figuring out # where routines are declared is hard. So people toss in dozens of use clauses # in order to avoid needing to do that (which would be needed for # fully-qualified calls). I agree that there is a language problem in that # case, but the solution isn't to make more forms of use clause! The prefix # call notation would avoid the need for the use clauses in the first place: # # My_Window.Show; # # does not need a package name nor a use clause. You have this point! - and the prefixed notation would be nice. [Ada.Numerics.Long_Elementary_Functions etc.] # It's rare that a standard package is heavily used enough to justify the use # of a use clause. Our statistics differ, Sir ! # > with Ada.Text_IO; use Ada.Text_IO; # > with Ada.Integer_Text_IO; use Ada.Integer_Text_IO; # > with Ada.Float_Text_IO; use Ada.Float_Text_IO; # > with Ada.Direct_IO; # > with Ada.Numerics; use Ada.Numerics; # > with Ada.Numerics.Elementary_Functions; use # Ada.Numerics.Elementary_Functions; # > with Ada.Unchecked_Deallocation; ... # Yikes again! This is precisely the sort of thing that should not happen for # a number of reasons. Personally, I almost never "use" Ada.Text_IO; it's # short enough to write out. Unfortunately I have a keyboard whithout programmable extra keys to write "Ada.Text_IO." at all places I need to write "Put". And even then I would hate polluting my sources with parasite verbosity... [...] # In any case, even if you like use clauses, you have to admit that this is # WAAAYY down on the priority list. Indeed I hope there are more important things to be implemented :-) . # This is not a case where something is hard # or impossible to do in the current language. So virtually every other # proposal (with the possible exception of the one changing the title of Annex # H) is more valuable. And this would be reasonably expensive to implement, as # it would require changes in not only the syntax but also the data structures # used for processing context clauses. Are you so sure ? It relies only on what the compiler does for a with_clause and a use_clause. It should be trivial to implement - after all "with and use A[,B]" = "with A[,B]; use A[,B]". # As well as changes to the make tool. So # this is neither real cheap (like changing the title of Annex H) nor real # important -- which means it probably doesn't make the cut. Ada 9x, after # all, had a number of good ideas that were left out of the final language # simply because they were not important enough. The same will be true with # Ada 200Y. My theory is that advanced features should of course have the priority, but a small basic thing like that should not be neglected in terms of pushing Ada a bit towards a growing orbital. **************************************************************** From: Pascal Leroy Sent: Monday, September 15, 2003 1:36 AM > Are you so sure ? It relies only on what the compiler does for a > with_clause and a use_clause. It should be trivial to implement - after all > "with and use A[,B]" = "with A[,B]; use A[,B]". Never say "trivial" when it comes to Ada. Equivalence rules never work. Examples of issues that would crop up with this proposal include: 1 - "with A.B" does an implicit "with A". "use A.B" doesn't do an implicit "use A". What should the rule be for "with and use"? 2 - There are also interactions with "private with" (AI 262) and "limited with" (AI 217). Should "private with and use A" be illegal? Or should it cause the use clause to take effect at the beginning of the private part? This reeks of Beaujolais effects... I am not saying that these questions cannot be answered satisfactorily, and perhaps they are no big deal, but they need to be studied. The RM cannot define a construct of the language by saying "you know, with-and-use, it does a with and a use..." **************************************************************** From: Gautier de Montmollin Sent: Tuesday, September 16, 2003 12:22 PM # Never say "trivial" when it comes to Ada. Sorry for the coarse word. I won't say it again. Promised. I'm sorry. # Equivalence rules never work. # Examples of issues that would crop up with this proposal include: # # 1 - "with A.B" does an implicit "with A". "use A.B" doesn't do an # implicit "use A". What should the rule be for "with and use"? Exactly the rule that applies for "with A.B; use A.B;": A.B and A are "with"ed, A.B only is "use"d here. As I see it, the above equivalence is really textual (a sort of meta-equivalence), all rules would follow (better so) exactly _as if_ the "with *; use *;" were written. # 2 - There are also interactions with "private with" (AI 262) and # "limited with" (AI 217). Should "private with and use A" be illegal? # Or should it cause the use clause to take effect at the beginning of the # private part? This reeks of Beaujolais effects... Clearly I would specify a "with and use" only. No "private with and use" or whatever. On there other hand it could be interesting to have another bottle to win... # I am not saying that these questions cannot be answered satisfactorily, # and perhaps they are no big deal, but they need to be studied. The RM # cannot define a construct of the language by saying "you know, # with-and-use, it does a with and a use..." I'm pretty confident that this issue will be discussed enough, and I'm sure that even if we tried to write such a phrasing into the RM it would erase it itself or at least try to raise an exception in the printing machine. **************************************************************** From: Gautier de Montmollin Sent: Wednesday, September 17, 2003 11:27 PM Jeffrey Carter: # If we're going to do something like, and I'm not convinced it's needed or # even desireable, then why not simply say that, in a context clause and # ONLY in a context clause, one can write # use X; # where X has not been mentioned before, and have it equivalent to # with X; use X; # ? This is a good idea. One has to verify that the "use X" without "with X" cannot refer accidentally to another previously visible "X". It might also change a bit how "use" has to search entities. I'd say: better idea, possible "Beaujolais" 's to chase (contrary to "with and use"). **************************************************************** From: David Wheeler Sent: Saturday, December 13, 2003 9:52 AM !subject Combine with and use clauses into "with use P" !reference RM95-10.1.2(4) !from David A. Wheeler 2003-12-13 !keywords with, use, visibility !difficulty Easy !problem Programs using many use clauses can become lengthy and require significant visual checking between package names in the with and use clauses. For example, if there are 10 with'ed packages, and 8 used packages, which packages were NOT used? And was that accidental or intentional? Most languages specify visibility with the importation statement to prevent this problem. !proposal Permit "with" clauses to be followed by an optional "use", in which case it has the effect of a with of the library unit names followed by a use of the same list (as defined in section 8.4). !wording Change with_clause to with_clause ::= with [use] library_unit_name {, library_unit_name}; Then state "If a with_clause includes the "use" option, then the visibility of the listed units is the same as if a use_package_clause had been used (as defined in 8.4)." !discussion This should be a trivial change to compilers, so the cost should be low. There are no backward-compatibility issues. **************************************************************** From: Nick Roberts Sent: Saturday, December 13, 2003 11:26 AM >!wording >Change with_clause to >with_clause ::= with [use] library_unit_name {, library_unit_name}; I completely endorse this amendment except for my (trivial) preference for "and use" rather than just "use". Even then, this is only a mild preference. !wording Change with_clause to with_clause ::= with [and use] library_unit_name {, library_unit_name}; **************************************************************** From: Martin Krischik Sent: Sunday, December 14, 2003 6:45 AM I speak against. To many "use" clauses make the code harder to understand therefore excessive use of "use" should not be made easier. On a side note the OP: '"use" is not only allowed on libraty level. You can "use" in procedures, declare etc. pp: procedure Some_String_Opreations is use Ada.Strings.Unbounded_Strings: begin .... It is much better to make the packages only visible where you actualy need them. **************************************************************** From: Robert A. Duff Sent: Saturday, January 17, 2004 2:26 PM Martin Krischik said: > I speak against. To many "use" clauses make the code harder to > understand therefore excessive use of "use" should not be made easier. I do not support the "with and use" idea, because it's not important enough. However, I disagree with the punitive school of language design expressed here. I agree with Martin that "use" should be used sparingly. However, I'm going to use it exactly where I think it's appropriate, and no more, and I don't need rules and regulations inhibiting me from using it. The language rules should be intended to prevent mistakes -- not to punish evil programmers with carpal tunnel syndrome. Nobody is going to type "use Some_Package" by accident! Suppose "Unchecked_Conversion" were called, say, "Cast". Would programmers then run around adding unchecked conversions all over the place, just because it's now easier to type? Of course not. Cast/U_C should be used sparingly, and isolated, and making me type a long name is not going to stop me from using it where I, the programmer, think it's a appropriate, and making the name short is not going to cause me to use it where (in my opinion) it's inappropriate. > On a side note the OP: '"use" is not only allowed on libraty level. You > can "use" in procedures, declare etc. pp: > > procedure Some_String_Opreations > is > use Ada.Strings.Unbounded_Strings: > begin > .... > > It is much better to make the packages only visible where you actualy > need them. Agreed, but I don't need no stinkin' language designer telling me that. ;-) I, the programmer, can make these decisions just fine thank you very much. By the way, I agree with Jeff Carter, who said (way back on 10 Sep 2003): > If we're going to do something like, and I'm not convinced it's needed > or even desireable, then why not simply say that, in a context clause > and ONLY in a context clause, one can write > > use X; > > where X has not been mentioned before, and have it equivalent to > > with X; use X; That would be the right approach. But it's not *quite* that simple, because "use" is legal in some cases where "with" is not (namely, nested packages). Jeff's rule would cause incompatibilities, because "use A.B.C;" is currently legal when C is nested in library package A.B, so the implied "with A.B.C;" would be illegal. So the rule should be "use A.B.C;" implies "with A.B;" or whatever prefix of the name is a library unit. This rule would be an improvement, because it would make context clauses where someone wisely chose to use use more readable. And when someone UNwisely chooses to use use -- well, I don't care; it's not our job as language designers to prevent that (it's hopeless anyway). **************************************************************** From: Martin Dowie Sent: Saturday, January 17, 2004 5:59 PM > I do not support the "with and use" idea, because it's not important > enough. However, I disagree with the punitive school of language design > expressed here. I don't support the idea (as a user of Ada) as AI-00252 has made it to "Amendment 200Y" status and this (I think) would cater for a large percentage of where people find "with and use" attractive... Vote "Yes" for AI-00252!! :-) **************************************************************** From: Jeffery Carter Sent: Saturday, January 17, 2004 7:24 PM Robert A Duff wrote: > By the way, I agree with Jeff Carter, who said (way back on 10 Sep > 2003): > >> If we're going to do something like, and I'm not convinced it's >> needed or even desireable, then why not simply say that, in a >> context clause and ONLY in a context clause, one can write >> >> use X; >> >> where X has not been mentioned before, and have it equivalent to >> >> with X; use X; By now I thought nobody had paid any interest to that post. > That would be the right approach. But it's not *quite* that simple, > because "use" is legal in some cases where "with" is not (namely, > nested packages). Jeff's rule would cause incompatibilities, because > "use A.B.C;" is currently legal when C is nested in library package > A.B, so the implied "with A.B.C;" would be illegal. So the rule > should be "use A.B.C;" implies "with A.B;" or whatever prefix of the > name is a library unit. I think I've never had a use clause in a context that didn't mention something that could also be in a with clause, so I didn't think of this problem. Perhaps the easiest solution would be to allow this notation only for library units, so the implied with would be legal. It the name is not a library unit, the use clause would be illegal. **************************************************************** From: Robert A. Duff Sent: Sunday, January 18, 2004 11:22 AM I don't see how that can work. The "notation" we're talking about is just the use_clause, and we can't make that notation illegal in cases where it is currently legal. Example: Suppose A.B is a library package, and C is a package nested in A.B. It is currently legal to say: with A.B; use A.B.C; Your rule above, if I understand it correctly, says "use A.B.C" is illegal, because A.B.C is not a library unit. **************************************************************** From: Jeffery Carter Sent: Sunday, January 18, 2004 11:43 PM You're probably right. It doesn't really matter, since Ada doesn't need something like this. **************************************************************** From: Martin Krischik Sent: Monday, January 19, 2004 10:51 AM > I agree with Martin that "use" should be used sparingly. However, I'm > going to use it exactly where I think it's appropriate, and no more, and > I don't need rules and regulations inhibiting me from using it. The > language rules should be intended to prevent mistakes -- not to punish > evil programmers with carpal tunnel syndrome. Nobody is going to type > "use Some_Package" by accident! While I accept the rest of your post I disacree on this one. I think I would be a rich man if I had a euro for every time some programmer (or text editor macro) typed: with xxxx; use xxxx; without thinking about it - i.E. xxxx is only referenced once. In comp.lang.ada I have seen more then one beginner who saw the above in there tutorial copied it without thinking and run head on into name clashes. But prehaps the problem are the tutorial writers. I was 6 month into Ada before found out that "use" is not library level only. **************************************************************** From: Alexandre E. Kopilovitch Sent: Monday, January 19, 2004 1:24 PM Perhaps the following form may provide a reasonable compromise: WITH package-name AND USE THIS PACKAGE; - with this form the repetition of the package-name is avoided without introducing of an unwanted shorthand. **************************************************************** From: Martin Dowie Sent: Tuesday, January 20, 2004 12:48 AM "THIS" isn't currently a reserved word and I know of at least one person :-) who uses it as an object name, particularly as a 'renames', in a lot of existing code... **************************************************************** From: Alexandre E. Kopilovitch Sent: Tuesday, January 20, 2004 11:51 AM > "THIS" isn't currently a reserved word Yes, but I meant that THIS is non-reserved keyword here. > and I know of at least one person :-) > who uses it as an object name, particularly as a 'renames', in a lot of > existing code... I think that person probably will agree with this usage of THIS as non-reserved keyword, because it is used here in closely related sense. **************************************************************** From: Gautier de Montmollin Sent: Wednesday, January 21, 2004 4:22 AM If I understand well, you want to introduce words that could be normal identifiers in some parts and keywords in others ? You have little chance with Ada... Should I remind that Borland led their dialect of Pascal to a total mess with that mistake ? **************************************************************** From: Pascal Leroy Sent: Tuesday, January 20, 2004 4:20 AM To all those involved in the recent "with and use" discussion on c.l.a. and ada-comment: I think it's worth reminding everyone that a proposal for "with and use" has been received by the ARG on September 9, 2003. In accordance with the ARG procedures, section 2 clause 4 (see http://www.ada-auth.org/ai-files/minutes/ARGprc20.PDF), it has been classified as "received no action" and Ada Commentary #78 has been created to record the proposal (see http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AC-00078.TXT?rev=1.1). What this means is that, no matter how much mail+news traffic is generated on this topic, it is not going to be part of the Ada 05 Amendment, unless two ARG members ask for the proposal to be reexamined (see the same clause of the ARG procedures). If some people feel strongly about "with and use", they should try to convince two ARG members to champion it, rather than indulge in endless chit chat on ada-comment. ****************************************************************