Version 1.2 of acs/ac-00078.txt

Unformatted version of acs/ac-00078.txt version 1.2
Other versions for file acs/ac-00078.txt

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

****************************************************************


Questions? Ask the ACAA Technical Agent