Elimination of "use" clauses

Elimination of "use" clauses

[Dr. Neil C. Audsley]

We have a lot of Ada source that "with"s and "use"s a lot of packages --
to the extent that it is difficult and time-consuming to find out which
package a procedure is actually from.
Ideally, we would like to eliminate "use" clauses, necessitating the
replacement of each procedure call X by PackageName.X instead.
Is there a tool that does this?


-- 
=========================================================================
Dr. Neil C. Audsley                Email:  neil@cs.york.ac.uk
Senior Research Fellow             Phone:  +44-1904-432787
Department of Computer Science,    Fax:    +44-1904-432708
University of York,
York. Y01 5DD, UK

Re: Elimination of "use" clauses

[Joe Wisniewski]

I don't know of any tools out there that do this.
Using ASIS, for detection of these occurrences would appear
to be the way to go. Then obviously a source modification
response.

What platform?
Which compiler and compiler vendor?

If you don't find a tool this is something that I might
like to take a crack at.

Joe


In article <377B5807.88B875E0@cs.york.ac.uk>,
  Neil.Audsley@cs.york.ac.uk wrote:
>
> We have a lot of Ada source that "with"s and "use"s a lot of packages
--
> to the extent that it is difficult and time-consuming to find out
which
> package a procedure is actually from.
> Ideally, we would like to eliminate "use" clauses, necessitating the
> replacement of each procedure call X by PackageName.X instead.
> Is there a tool that does this?
>
> --
>
========================================================================
=
> Dr. Neil C. Audsley                Email:  neil@cs.york.ac.uk
> Senior Research Fellow             Phone:  +44-1904-432787
> Department of Computer Science,    Fax:    +44-1904-432708
> University of York,
> York. Y01 5DD, UK
>


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[czgrr]

In article <377B5807.88B875E0@cs.york.ac.uk>,
  Neil.Audsley@cs.york.ac.uk wrote:
> Ideally, we would like to eliminate "use" clauses, necessitating the
> replacement of each procedure call X by PackageName.X instead.
> Is there a tool that does this?

I don't know about a tool to do it automatically, but it would seem
that the easiest way to do it manually, if you have to, is to remove
one "use", recompile all and see what fails. Add in "package_name."s
until everything compiles again, and repeat for all "use"s.

If you are using a compiler which has an "Show definition of..."
operation (like ObjectAda, for example), you can use that to find the
package that a function call is in, but this may be more tedious than
getting the compiler to find them all for you.

P.S. Watch out for operators. Having added all the "package_name."s, it
sometimes makes for better readability if you re-introduce the "use"
(globally or in specific routines) solely for the purpose of accessing
operators. Remember to comment it as such.

P.P.S. Totally my opinion here, and I'm sure that a discussion of some
sort will ensue as a result of this, but I believe that if one package
is heavily accessed in another, then that normally justifies having a
"use". Similarly, if there is a globally used, low-enough-level package
(like one for a program-wide set of base declarations), then I "use"
that package everywhere that I "with" it as standard. But it's up to
you.

Cheers,
czgrr

--
No email, please - reply to the newsgroup.
My opinions are not necessarily those of my
employer.
Use any suggestions at your own risk.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Ted Dennison]

In article <7lfvbk$fhh$1@nnrp1.deja.com>,
  czgrr <czgrr@my-deja.com> wrote:
> In article <377B5807.88B875E0@cs.york.ac.uk>,
>   Neil.Audsley@cs.york.ac.uk wrote:
> > Ideally, we would like to eliminate "use" clauses, necessitating the
> > replacement of each procedure call X by PackageName.X instead.
> > Is there a tool that does this?
>
> P.S. Watch out for operators. Having added all the "package_name."s,
it
> sometimes makes for better readability if you re-introduce the "use"
> (globally or in specific routines) solely for the purpose of accessing
> operators. Remember to comment it as such.

Good point. But as a fellow "use-phobe", I think Neil would probably
prefer to put in "use type" statements to get access to the comparison
and mathematical operators that he will loose when the "use" clauses are
removed.

But YMMV.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[czgrr]

In article <7lg0sg$g8q$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> Good point. But as a fellow "use-phobe", I think Neil would probably
> prefer to put in "use type" statements to get access to the comparison
> and mathematical operators that he will loose when the "use" clauses
are
> removed.

"use type" - is that new in Ada95 then? Also, for us Ada83'ers, I
suppose a "renames" declaration could be used instead of a "use" on the
whole package.

czgrr

--
No email, please - reply to the newsgroup.
My opinions are not necessarily those of my
employer.
Use any suggestions at your own risk.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Ted Dennison]

In article <7lhmps$3ll$1@nnrp1.deja.com>,
  czgrr <czgrr@my-deja.com> wrote:
> In article <7lg0sg$g8q$1@nnrp1.deja.com>,
>   Ted Dennison <dennison@telepath.com> wrote:
> > Good point. But as a fellow "use-phobe", I think Neil would probably
> > prefer to put in "use type" statements to get access to the
comparison
> > and mathematical operators that he will loose when the "use" clauses
> are
> > removed.
>
> "use type" - is that new in Ada95 then? Also, for us Ada83'ers, I
> suppose a "renames" declaration could be used instead of a "use" on
the
> whole package.

Exactly. "use type"'s purpose in life is pretty much to keep us
use-phobes from having to put all those operator renames at the top of
our package bodies.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Samuel T. Harris]

"Dr. Neil C. Audsley" wrote:
> 
> We have a lot of Ada source that "with"s and "use"s a lot of packages --
> to the extent that it is difficult and time-consuming to find out which
> package a procedure is actually from.
> Ideally, we would like to eliminate "use" clauses, necessitating the
> replacement of each procedure call X by PackageName.X instead.
> Is there a tool that does this?
> 

Rational Apex has a "complete" facility which fully expands
name of things, adds named notation. It can be used on
already written constructs (your case) or on a partitial
or even ambiguous call. If only partitial, it will fill in
any missing parameters using named notation and use a
[some_type_expression] as a filler for the missing actual
parameters. If ambigous, it open a window with a list of
possible candidates. You can "visit" each candidate to
determine which one you need. The problem with this
facility is that it used to work on a selection of
code text but now only works on one statement at a time.
Works good while supporting the writing of code but is
very clumsy to use to retro-format existing code.

As far as your general problem is concerned, if you audience
reading the code can do it on-line, then a solution is to
use one of the many tools which provide a similar "visit"
function. Apex, Emacs with ada-tags, or ada2html from
David Wheeler all come to mind.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Scientific and Technical Systems
"If you can make it, We can fake it!"

Re: Elimination of "use" clauses

[Robert Dewar]

In article <377B5807.88B875E0@cs.york.ac.uk>,
  Neil.Audsley@cs.york.ac.uk wrote:
>
> We have a lot of Ada source that "with"s and "use"s a lot of
packages --
> to the extent that it is difficult and time-consuming to find
out which
> package a procedure is actually from.
> Ideally, we would like to eliminate "use" clauses,
necessitating the
> replacement of each procedure call X by PackageName.X instead.
> Is there a tool that does this?

I don't know of a dotification tool, but it seems strange to
claim that it is difficult and time-consuming to find out
which package a procedure is from. That sounds like you are
not using appropriate tools. Try using the EMACS interface
to GNAT, and you can immediately go from any identifier to
the declaration (and the proper package in which this
declaration appears). This is actually much more useful in
reading code, since you immediately find out not only what
package the identifier is in, but you go to the declaration
which shows you the details of what the identifier means.

There are other tools that have this same capability. This
seems pretty important functionality. There is also the gnatfind
utility available with GNAT for providing this same kind of
information in command line mode.

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Samuel T. Harris]

Robert Dewar wrote:
> 
> In article <377B5807.88B875E0@cs.york.ac.uk>,
>   Neil.Audsley@cs.york.ac.uk wrote:
> >
> > We have a lot of Ada source that "with"s and "use"s a lot of
> packages --
> > to the extent that it is difficult and time-consuming to find
> out which
> > package a procedure is actually from.
> > Ideally, we would like to eliminate "use" clauses,
> necessitating the
> > replacement of each procedure call X by PackageName.X instead.
> > Is there a tool that does this?
> 
> I don't know of a dotification tool, but it seems strange to
> claim that it is difficult and time-consuming to find out
> which package a procedure is from. That sounds like you are
> not using appropriate tools. Try using the EMACS interface
> to GNAT, and you can immediately go from any identifier to
> the declaration (and the proper package in which this
> declaration appears). This is actually much more useful in
> reading code, since you immediately find out not only what
> package the identifier is in, but you go to the declaration
> which shows you the details of what the identifier means.
> 
> There are other tools that have this same capability. This
> seems pretty important functionality. There is also the gnatfind
> utility available with GNAT for providing this same kind of
> information in command line mode.

There are times when no tool can be of any help.
Doing work for NASA, we have customers which insist on
reviewing code in their private work area. With no
connectivity to our environment, they do not have
access to our tools. Some of they even require hardcopy
and reject any electronic form.

So the problem is not entirely handled by good tools.
Reasonable restrictions on the use clause are still
appropriate to support such edge cases.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Scientific and Technical Systems
"If you can make it, We can fake it!"

Re: Elimination of "use" clauses

[Robert Dewar]

In article <377CE178.6C15F543@hso.link.com>,
  "Samuel T. Harris" <sam_harris@hso.link.com> wrote:
> There are times when no tool can be of any help.
> Doing work for NASA, we have customers which insist on
> reviewing code in their private work area. With no
> connectivity to our environment, they do not have
> access to our tools. Some of they even require hardcopy
> and reject any electronic form.

Well there are people who refuse to drive automobiles, but
that does not mean that we necessarily take into account
those requirements in deciding how to layout our highways.
You may also have customers who require Hungarian notation,
but that does not mean it is a good thing.

Yes, of course a dotifier (or for that matter a Hungarianizer)
may be useful in bizarre environments

> So the problem is not entirely handled by good tools.
> Reasonable restrictions on the use clause are still
> appropriate to support such edge cases.

Well be careful. By supporting such edge cases, you may be
making the programs harder to read and work with by everyone
else.

As I pointed out in a previous message, it is actually
relatively unusual for people to fully qualify, that is
especially true in these days of child packages.

Do you really want to say:

   X := Ada.Numerics.Float_Random.Random (Gen);

rather than

   X := Random (Gen);

?
and that is by NO means the worst case. Well if you are really
usephobic, or worse, live in an environment which mandates that
use be disallowed (I have encountered such absurdities), then
you end up doing a package renaming:

   X := NFR.Random (Gen);

But this is *precisely* no help at all if you have decent
tools, and creates useless noise. It does not tell you
immediately where something is. The only purpose of the
prefix NFR is to help you find the declaration of Random
using decrepit tools. That to me is hard to justify.

Once again, I think the critical factor is to consider what
makes the code clearer. If you have people who insist on wasting
their time by reading the code on paper, by all means get a
dotifying tool and give them the entire long form above if
that's what they want!

Note that I am not arguing against qualification, just trying to
stress that the decision to qualify should be based on factors
other than the requirement of using decrepit tools. Of course
there are those who have no choice. Fine, but that does not
provide a source of inspiration on what ideal Ada style should
be in an ideal environment.

(actually for me, I agree with what someone wrote earlier, any
Ada environment not providing this capability is broken and
unusable as far as I am concerned). Even if you use FULL
qualification, it is nowhere NEAR as convenient as going
directly to the declaration with a decent tool. If you have
not tried working in such an environment, give it a try, you
may find it enlightening (and not have to reach so often for
the baseball bat :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Michael F. Yoder]

Ted Dennison wrote:
> 
> In article <7ljbsu$ni7$1@nnrp1.deja.com>,
>   Robert Dewar <robert_dewar@my-deja.com> wrote:
> 
> > and that is by NO means the worst case. Well if you are really
> > usephobic, or worse, live in an environment which mandates that
> > use be disallowed (I have encountered such absurdities), then
> > you end up doing a package renaming:
> >
> >    X := NFR.Random (Gen);
> 
> Interesting strawman. But the enviroments I have worked in tend to
> highly discourage "renames" as well. So instead you are "stuck" using
> full dot notation.

Not a strawman.  The best ways of dealing with use clauses are what I
call "Tony Tye" methods (since he devised the first one I used) and make
package renamings a staple.

The basis of these methods is to have a simple package renaming, at the
top of a unit, for every "withed" package; this renaming provides an
abbreviated name for that package within the unit.  If you like acronyms
you might use ASU for Ada.Strings.Unbounded and ASWU for
Ada.Strings.Wide_Unbounded.  I'd more likely use, e.g., Unb and WUnb. 
It is helpful but not necessary to keep these abbreviations consistent
across units.  Most (or all) identifiers denoting entities in the
"withed" packages are then prefixed by an abbreviated name and a dot.

A strict "Tony Tye" method would forbid 'use' and 'use type' clauses
entirely.  A loose one would allow all 'use type' clauses, and also
allow 'use' for all predefined packages and at most one non-predefined
package.  The point to the "at most one" rule is that it enables you to
(usually) know at a glance where any identifier is declared: if X isn't
from any surrounding scope, and you know the predefined packages well
enough to tell X isn't from one of them, it must be in the single
special used package.

My personal preference is to be fairly free about 'use type' (but to
drive it into the narrowest scope possible) and to otherwise lean
towards no use clauses at all.  I'll admit I sometimes allow myself two
used packages if one is Ada.Text_IO.

This is better than using fancy tools because even if the tool use is as
simple as double-clicking on the identifier, that's more distracting
than having the information immediately evident.  It requires no
conscious thought or finger movement to realize that 'Unb.Insert' comes
from the unbounded strings package.

"Use-phobia" of this sort usually aids code reading, whether the code is
hardcopy or not.

----
Michael Yoder

Re: Elimination of "use" clauses

[Richard D Riehle]

In article <3784DC54.6463EDCA@decada.zko.dec.com>,
	"Michael F. Yoder" <yoder@decada.zko.dec.com> wrote:

>Not a strawman.  The best ways of dealing with use clauses are what I
>call "Tony Tye" methods (since he devised the first one I used) and make
>package renamings a staple.

This is a widely used technique.  It does not completely solve the 
use clause question.   What problem are we trying to solve?

Ada is unique in its separation of scope from visibility.  In any
other language we would not even be discussing this issue.  As 
noted earlier, the rules of Ada are analogous to default insulation on
every entity.  With most languages we have code that is the equivalent
of bare wires running all over the place.  Cavalier coding of the use
clause is the same as removing all that nice insulation.

Ada permits us to remove the insulation at appropriate places. We would
never expect a consumer to go around scraping insulation from electrical
wires in the home.  We should not expect clients of packages to do the
same.  Instead, we should carefully expose, in our package design, those
places where entities can safely connect with each other.  This is a key
difference between engineering and programming.  

The use clause, when invoked willy-nilly, exposes too much of the
bare wire.  The use type is not much better, but one can see its
usefulness in teaching environments.  At the same time, excessive
paranoia over the use clause is usually unwarranted.  

In my earlier posting on this topic I said that the designer, not the
client/consumer, should be responsible for deciding what should be 
exposed and what should be hidden.  That is the purpose of creating
restricted operator packages that can be referenced via the use clause.
If a package is properly designed, the use clause applied to the 
restricted set of operators will be both easier to "use" and safer than
many of the alternatives.  We as designers need to take responsibility
for this.  Admittedly, most Ada packages in the existing software
repositories have fallen short in addressing this issue.  We can correct
this in future designs.

Richard Riehle
richard@adaworks.com
http://www.adaworks.com

Re: Elimination of "use" clauses

[Michael F. Yoder]

Richard D Riehle wrote:
> 
> In article <3784DC54.6463EDCA@decada.zko.dec.com>,
>         "Michael F. Yoder" <yoder@decada.zko.dec.com> wrote:
> 
> >Not a strawman.  The best ways of dealing with use clauses are what I
> >call "Tony Tye" methods (since he devised the first one I used) and make
> >package renamings a staple.
> 
> This is a widely used technique.  It does not completely solve the
> use clause question.   What problem are we trying to solve?

Perhaps there is a difference in perception, or in experience, here.

In my experience, the described method does in fact completely solve the
problem of use clauses contributing to code obfuscation (for
identifiers, and for all practical purposes).  It does not, in my
opinion, necessarily provide the best solution for operators.  I'd
prefer to have the two questions separated, and I have no strong
opinions to contribute to the discussion about operators.

On the project Tony Tye led, complaints about use clauses simply didn't
occur after the method was introduced.  I don't know of any instance in
which introducing such a method led to a perceived reduction in
readability, but perhaps those participating in this discussion can
contribute some.  :-)

Re: Elimination of "use" clauses

[Marin David Condic]

Richard D Riehle wrote:
> 
> Ada permits us to remove the insulation at appropriate places. We would
> never expect a consumer to go around scraping insulation from electrical
> wires in the home.  We should not expect clients of packages to do the
> same.  Instead, we should carefully expose, in our package design, those
> places where entities can safely connect with each other.  This is a key
> difference between engineering and programming.
> 
I think I can agree that package designers can/should help make
decisions about what should be directly visible, via some version of the
_Ops package, but don't you think that a lot of visibility issues are
going to depend on the caller? I mean, when I buy a 100 feet of wire at
The Home Depot, I expect the *default* to be that it is insulated so
that I don't string it through my attic and produce hazards where I
least expect it. But with a trusty pair of wire dykes I expect to strip
& connect where my application demands.

I personally like to limit the "use" clause to the smallest scope
possible - If I'm using Ada.Strings.Unbounded somewhere in a package, I
may use explicit dotted notation on the parameters of the subprograms,
but within the subprogram itself, apply the "use" clause to eliminate
the clutter. The caller of my package then knows where to find the data
types for the parameters, but within the package we kind of assume that
someone will recognize "Move" and "To_String" as being operations from
A.S.U. But it was *my* decision about what is clear and what may be
obfuscated within the context of my application.

> The use clause, when invoked willy-nilly, exposes too much of the
> bare wire.  The use type is not much better, but one can see its
> usefulness in teaching environments.  At the same time, excessive
> paranoia over the use clause is usually unwarranted.
> 
I think it tends to be a tempest in a teapot. In practice, I think
clarity is more a result of the talent of the programmer rather than the
language features. Someone who thinks, speaks and writes clearly is
likely to produce code that communicates its intentions clearly with or
without the use clause. I think the advantage of the use clause is more
one of protecting the namespace than one of clarity/obfuscation. If the
given caller has no ambiguities or collisions with the names of the
withed package, the use clause is probably not going to hurt the clarity
much. If there are collisions, then avoid the use clause. (Except for
infix operators! There's nothing uglier than seeing 'My_Package."<" (L,
R)' ;-)

In general, eschew obfuscation. :-)

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Elimination of "use" clauses

[Robert Dewar]

In article <3784DC54.6463EDCA@decada.zko.dec.com>,
  "Michael F. Yoder" <yoder@decada.zko.dec.com> wrote:
>  It requires no
> conscious thought or finger movement to realize that
> 'Unb.Insert' comes
> from the unbounded strings package.


Or perhaps unbounded trees, or perhaps the
Universal_National_Boundaries package?

I personally dislike these kind of package abbreviations. They
are fine for people who know the code well, but they probably
know where stuff is anyway.

Otherwise you constantly have to be searching back to find out
what peculiar abbreviations have been used.

A good rule, one that is required in many Ada coding standards,
is no abbreviations. I see no reason why this rule should not
apply to renamings of packages, but in my experience, people are
so desparate to have very short names when they have to type
them all over the place, that they choose very short cryptic
abbreviations (I consider incidentally that Unb for
Ada.Strings.Unbounded is in that category).

This is a matter of taste of course, and there are many styles,
but this is the one I like least. I would prefer to see honest
full qualification, rather than cryptic abbreviations.

And as for USE TYPE, anyone who thinks it is acceptable to say

  X := Special_Operation_Types."+"(A,B);

does not have my sympath, and replacing this with

  X := SOT."+"(A,B);

is not helpful.

Yes, of course you can use renamings, but what possible value
is this. If you see:

  X := A + B;

then it is *definitely* useful to be able to click on the "+"
to quickly check if this plus is other than a standard one
(perhaps a really nice tool would paint such operators in a
different color). But looking at a bunch of renaming operations
for "+" at the front of the package and then trying to figure
out if one of them applies, given the types of A and B is no
fun.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Dale Stanbrough]

Robert Dewar wrote:

   This is a matter of taste of course, and there are many styles,
   but this is the one I like least. I would prefer to see honest
   full qualification, rather than cryptic abbreviations.

I have a package that only withs Ada.Text_IO, and the package defines
it's own put procedures. Instead of Ada.Text_IO.Put (...) (or Text_IO.Put)
I have a renames to ATIO which IMHO is readable (but mainly because
there is only one with).

I would think that the Ada heirachy could be renamed to shorter names
if...

   there are very few withs in the unit

   the contractions are standardized (first letter of each word in
   a package name. e.g. Ada.Strings.Unbounded => ASU, Ada.Stream_IO
   => ASIO etc)

   the renamings only occur within a unit, and not at the library level

without causing too much distress.

Dale

Re: Elimination of "use" clauses

[Robert Dewar]

In article <dale-0907991223380001@dale.cs.rmit.edu.au>,
  dale@cs.rmit.edu.au (Dale Stanbrough) wrote:

> I would think that the Ada heirachy could be renamed to
> shorter names if...

My preferred approach would be to forbid any user packages
from duplicating the names used in the RM in Annex A and
other standard packages, unless there is a very definite
methodological reason for the duplication (e.g. defining
a Put procedure for additional types).

If this is followed, then since all these names are familiar
to Ada programmers, I see no reason to use such package
abbreviations for these names. On the contrary, such
abbreviations may indeed imply that you are NOT using
the standard routines.

If you must prefix the routines, I will say again, that I
prefer

Ada.Text_IO.Put

to

ATIO.Put

This is certainly a matter of taste, but the objection to
abbreviations is a pretty common one, and as I said before,
many style guides discourage or forbid abbreviations (what
has AQ&S to say on the abbreviation issue).


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Ted Dennison]

In article <7mdml7$vo4$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> My preferred approach would be to forbid any user packages
> from duplicating the names used in the RM in Annex A and
> other standard packages, unless there is a very definite
> methodological reason for the duplication (e.g. defining
> a Put procedure for additional types).

That's a pretty hefty set of useful names you are putting off-limits!
For instance:
  "Move", "Index", "Count", "Insert", "Delete" (Ada.Strings.Fixed)
  "Split" (Ada.Calendar)
  "Read", "Write" (Ada.Storage_IO, Ada.Streams)
  "Create", "Reset", "Name" (Ada.Text_IO)
  "Initialize", "Adjust" (Ada.Finalization)
  "Size" (Ada.Direct_IO)

Looking over this list, its interesting how much more sense each makes
at first glance when given the context of its package name...

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Michael F. Yoder]

Robert Dewar wrote:
> 
> In article <3784DC54.6463EDCA@decada.zko.dec.com>,
>   "Michael F. Yoder" <yoder@decada.zko.dec.com> wrote:
> >  It requires no
> > conscious thought or finger movement to realize that
> > 'Unb.Insert' comes
> > from the unbounded strings package.
> 
> Or perhaps unbounded trees, or perhaps the
> Universal_National_Boundaries package?

This is not a reasonable objection, because it assumes the worst
possible usage of the method.  (This *is* a strawman argument.)  If both
unbounded strings and unbounded trees were "withed" units, the
abbreviations would be something like UStr and UTree.  And
Universal_National_Boundaries would be abbreviated UNB, not Unb, if you
chose to allow acronyms.  (Using case to improve readability is
desirable even in a case-insensitive language.)

> I personally dislike these kind of package abbreviations. They
> are fine for people who know the code well, but they probably
> know where stuff is anyway.
>
> Otherwise you constantly have to be searching back to find out
> what peculiar abbreviations have been used.

This simply isn't so in my experience.  It takes at most one or two
readings of the renamings to internalize them.  If you are aware of the
method, you treat the renamings as an extension of the context clause;
and of course you should habitually read the context clause of a unit
before reading the unit.  Even if you aren't aware of the method, you
should read the global declarations at the top of a unit body.

It might be useful to this thread to give some history of the method I
discussed.  It was devised precisely because there was general
disgruntlement in our project about unreadability of code induced by
overly generous usage of use clauses.  On that project, the method
simply solved the problem.  Ever since then, I've not seen any case
where introducing such methods (or moving closer to them) hasn't
improved code readability even months or years after such changes.  To
me, the superiority of the method is an observed empirical fact; nor is
it a matter of what I am used to, since it wasn't the first method I
used.  I would certainly be willing to risk large amounts of money on
the method's being better than most others.

> [material about operators omitted]

Operators I prefer to treat as a separate question, because I believe
the best solution is different for operators and identifiers.  I have a
personal preference, but I don't feel it is clearly superior to other
methods.  With identifiers my experience has led me to a strong
preference.

Re: Elimination of "use" clauses

[Tucker Taft]

Michael F. Yoder wrote:
> ...
> This simply isn't so in my experience.  It takes at most one or two
> readings of the renamings to internalize them.  If you are aware of the
> method, you treat the renamings as an extension of the context clause;
> and of course you should habitually read the context clause of a unit
> before reading the unit.  Even if you aren't aware of the method, you
> should read the global declarations at the top of a unit body.

For what it is worth, we have used the package renaming approach
in our all of our tools since 1980.  Probably about a million lines
of code all told, counting the AIE and derivatives thereof.

We certainly tried to have project-wide agreement on the official
short name for every package.  Even when there were local variations,
it was still quite manageable.  (In Ada 95 you have an option of actually
putting the official short names into the library using library-unit renames,
though I'm not sure whether it is a good idea to take advantage of
that for this purpose.)  

In any case, we quite rapidly reached the point that we all
knew the short names by heart, and it significantly improved the
signal-to-noise ratio compared to using full package names everywhere,
and minimized the mystery associated with using multiple use clauses.

Of course, as in all of these things, your mileage may vary.  But
we at least have gotten very good mileage out of the package rename approach,
and I would suggest other shops give it a try to see whether it solves
their problems.  Combined with "use type" for operators, it has worked even
better for us in Ada 95.


-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Elimination of "use" clauses

[Simon Wright]

Robert Dewar <robert_dewar@my-deja.com> writes:

> I personally dislike these kind of package abbreviations. They
> are fine for people who know the code well, but they probably
> know where stuff is anyway.

I first came across consistent renamings like this in the GNAT sources:

  package body System.Pool_Global is

     package SSE renames System.Storage_Elements;

and thought it a pretty cool notion. is ACT changing its style, then?
(your privilege, of course!)

Re: Elimination of "use" clauses

[Robert Dewar]

In article <x7vso6xvsbw.fsf@pogner.moho>,
  Simon Wright <simon@pogner.demon.co.uk> wrote:

> I first came across consistent renamings like this in the GNAT
> sources:
>
>   package body System.Pool_Global is
>
>      package SSE renames System.Storage_Elements;
>
> and thought it a pretty cool notion. is ACT changing its
style, then?
> (your privilege, of course!)

First: ACT /= Dewar. Just because I like something does not
mean my preference is what we do (I prefer all upper case
identifiers, but everyone else preferred mixed case, so that's
what we use, and now I am used enough to that and it is OK).

As for the specs, as you know, we have a convention of not
allowing use clauses in internal library packages that is
inspired by the rtsfind restrictions. General GNAT style is
to prefer general use of use clauses.

Most certainly we would not get into prefixing uses of
system.storage_units if it were not for the rtsfind
restrictions (se the GNAT sources if you want to find
out more about that).

But anyway, if you think this notation is cool, fine .. I find
it OK for very small units like these, but it is not something
I would use in larger units. For example, if you look at
g-spipat.adb, which I *did* write, it is 6000 lines long (the
SPITBOL pattern matching stuff is complex -- half is comments
but half is real code), and there is not one use of package
renaming, but there are use clauses, and this represents my
preferred style. Of course we DO have tools that allow us
to immediately locate a specific reference, and we use naming
conventions that minimize confusion.

One of the things I often see happening in big projects is that
there is simply no management control over the global name
space, so all kinds of different styles of naming coexist in
a program. I find that *really* horrible, and it does for sure
make it harder to figure out where things are.

In GNAT, if you see a name like Expand_N_Task_Body, you know
it must be in exp_ch9.adb, since it is clearly an expansion
routine, and you know that tasks are in chapter 9. The use
of Exp_Ch9.Expand_N_Task_Body would be entirely gratuitous
for anyone with the slightest familiarity with these sources
(and indeed annoying).

So part of the issue here is definitely control of name spaces.
I certainly agree that explicit naming may be more useful
when you have lost control of the name space.

One additional point, I really object to the use of
explicit qualification for dynamically overloaded primitive
operations of tagged types. Pointing back to the parent unit,
which is where the declaration is, but most certainly is NOT
where the executable code can be found, can often be quite
confusing.

If you see

   Module_Methods.List_Module;

it is an invitation to go to the body of Module_Methods to find
the code being executed, and of course in some sense the whole
idea of object oriented programming that makes use of dyamic
dispatching is that you CANNOT tell at the source level where
the code for some operation is located. Yes, it can correctly
point to the declaration, but far too often the declarations
are not sufficiently commented, and the feeling that the body
is a legitimate place to go to look to see how something works
is a common one, and one that can not be avoided with a lot of
inadequately commented code.

There, that should start another interesting subthread in the
old use discussion (incidentally, so far this thread has not
generated even one tiny small point that is new, but it seems
to be something that people like to talk about :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[R. Tim Coslet]

Our coding standard prohibits "use", except for "use type" (because
operator "renames" as we did in Ada83 get awful messy).

Our coding standard USED to prohibit all use of "renames" (except for
operators) for just the reason you give below: renaming packages to get
short dot notation form simply obscures the code.

They did finally loosen up on "renames" after seeing how a rename of an
array reference or list reference inside a loop or subprogram works (and
usually clues in the compiler to only do the index calculation ONCE
instead of on every reference).

Of course one has to realize that our entire coding standard was
developed when our "environment" consisted of nothing but VAX LSE, an
Ada83 compiler, and CCC. It is in review for potentially significant
changes.

Robert Dewar wrote:

> In article <377CE178.6C15F543@hso.link.com>,
>   "Samuel T. Harris" <sam_harris@hso.link.com> wrote:
>
> and that is by NO means the worst case. Well if you are really
> usephobic, or worse, live in an environment which mandates that
> use be disallowed (I have encountered such absurdities), then
> you end up doing a package renaming:
>
>    X := NFR.Random (Gen);
>
> But this is *precisely* no help at all if you have decent
> tools, and creates useless noise. It does not tell you
> immediately where something is. The only purpose of the
> prefix NFR is to help you find the declaration of Random
> using decrepit tools. That to me is hard to justify.
>
>
> (actually for me, I agree with what someone wrote earlier, any
> Ada environment not providing this capability is broken and
> unusable as far as I am concerned). Even if you use FULL
> qualification, it is nowhere NEAR as convenient as going
> directly to the declaration with a decent tool. If you have
> not tried working in such an environment, give it a try, you
> may find it enlightening (and not have to reach so often for
> the baseball bat :-)
>

Re: Elimination of "use" clauses

[Robert Dewar]

In article <3784F737.A04F466D@kaisere.com>,
  "R. Tim Coslet" <coslett@kaisere.com> wrote:
> Our coding standard USED to prohibit all use of "renames"
> (except for operators) for just the reason you give below:
> renaming packages to get short dot notation form simply
> obscures the code.

A nice example of crippling the language in the name of
controlling style! Renames is an absolutely critical feature
of the language. It is important for abstraction purposes, and
provides essential expressive power not at all easily replaced
by any other means.

For example if we have

    X : integer renames a(i,j).x1(k);

it is really horrible to do

    Capture_I : constant integer := i;
    Capture_J : constant integer := j;
    Capture_K : constant integer := k;

and then replace subsequent uses of X by

    A (Capture_I, Capture_J).x1(Capture_K);

And of course I am assuming A and x1 are declared objects and
not pointers, or things get even more ludicrous.

> They did finally loosen up on "renames" after seeing how a
> rename of an array reference or list reference inside a loop
> or subprogram works (and usually clues in the compiler to only
> do the index calculation ONCE instead of on every reference).

A decent compiler should do this automatically in almost all
cases without the need for renames, but in any case this is a
lousy reason for modifying the standards (ok, we will write
what we think is kludgy code because our compiler generates
better code if we do).

The proper reason for loosening up on this rule is that there
is no point in removing critical features of the language
without very good reason. Worrying about misuse in package
namings is not a "very good reason".

Almost all rules on Ada style that prohibit the use of a feature
entirely are misguided. I say almost all, because there are
definite examples, which are not so much style rules, as usage
rules, e.g. don't use dynamic allocation in safety critical
programs. They typically correspond to the use of pragma
Restrictions.

Going back to the use clause case,
if you prohibit use completely, and do not allow package
renamings, then you provoke another common disease, short
cryptic package names.

And please note that all this gets *MUCH* worse with child
packages in Ada 95. No doubt some brilliant manager will
prohibit the use of child packages because it leads to unwieldy
names :-)

> Of course one has to realize that our entire coding standard
> was developed when our "environment" consisted of nothing but
> VAX LSE, an Ada83 compiler, and CCC. It is in review for
> potentially significant changes.

It is definitely reasonable to take environment and tools into
effect when designing coding standards. The package renaming
for example is not unreasonable if you really are confined to
reading all code on paper.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[tmoran]

> No doubt some brilliant manager will prohibit the use of
> child packages because it leads to unwieldy names :-)
(Quite) some years ago I did a COBOL project for Intel.  The
manager wanted all paragraph names to be sequential numbers.
#.#

Re: Elimination of "use" clauses

[Ted Dennison]

In article <7lh74s$v36$1@nnrp1.deja.com>,
  Robert Dewar <dewar@gnat.com> wrote:
> In article <377B5807.88B875E0@cs.york.ac.uk>,
>   Neil.Audsley@cs.york.ac.uk wrote:
> >
> > We have a lot of Ada source that "with"s and "use"s a lot of
> packages --
> > to the extent that it is difficult and time-consuming to find
> out which
> > package a procedure is actually from.
> I don't know of a dotification tool, but it seems strange to
> claim that it is difficult and time-consuming to find out
> which package a procedure is from. That sounds like you are
> not using appropriate tools. Try using the EMACS interface

While I appreciate the fact that *some* compiler systems have facilites
to help decipher stuff like this under *certian* circumstances, I am not
persuaded that obtuse source code is just a "tool problem".

If I have to use specialized tools to figure out what someone's source
code is doing, the tool that springs most readily to mind is a baseball
bat...

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Stephen Leake]

Ted Dennison <dennison@telepath.com> writes:

> In article <7lh74s$v36$1@nnrp1.deja.com>,
>   Robert Dewar <dewar@gnat.com> wrote:
> > In article <377B5807.88B875E0@cs.york.ac.uk>,
> >   Neil.Audsley@cs.york.ac.uk wrote:
> > >
> > > We have a lot of Ada source that "with"s and "use"s a lot of
> > packages --
> > > to the extent that it is difficult and time-consuming to find
> > out which
> > > package a procedure is actually from.
> > I don't know of a dotification tool, but it seems strange to
> > claim that it is difficult and time-consuming to find out
> > which package a procedure is from. That sounds like you are
> > not using appropriate tools. Try using the EMACS interface
> 
> While I appreciate the fact that *some* compiler systems have facilites
> to help decipher stuff like this under *certian* circumstances, I am not
> persuaded that obtuse source code is just a "tool problem".
> 
> If I have to use specialized tools to figure out what someone's source
> code is doing, the tool that springs most readily to mind is a baseball
> bat...

The code reading tool is no more "specialized" than the compiler!

Borland provides a similar tool for C++, and DEC Ada 83 provided a
similar tool in conjunction with LSE. ObjectAda and GNAT both provide
such tools; I would reject any compiler that did not. 

With such a tool, you can understand more complex programs than
without such a tool. It is just one more aspect of the art of
programming.

Of course, there is no substitute for well written code, but I have no
problem assuming the availability of appropriate code reading tools
when judging what is well written.

For instance, I find it harder to read code without syntax
colorization. I don't think this is a problem, since colorization is
so widely available. The same is now true of cross reference tools;
they are widely available, so I am comfortable relying on them.

-- Stephe

Re: Elimination of "use" clauses

[Robert Dewar]

In article <7ligdq$c8q$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> While I appreciate the fact that *some* compiler systems have
> facilites to help decipher stuff like this under *certian*
> circumstances, I am not
> persuaded that obtuse source code is just a "tool problem".

Actually there are many of us who feel that using dotted
notation all over the place actually obscures the code,
especially once you know it fairly well. I personally find
the dots annoying -- why? well you have far more text which
is conveying no more semantic information. I find this only
one step removed from the use of Hungarian notations. Of
course I realize other people differ, but there are two kinds
of use phobes:

 a) people who really prefer the dots

 b) people who put up with the dots because it is the only
    reasonable way they have of finding things

Please understand that my message is addressed exclusively
to the second group :-)

> If I have to use specialized tools to figure out what
> someone's source code is doing, the tool that springs most
> readily to mind is a baseball bat...

In a decent Ada environment, this should not be considered
a specialized tool, but rather a necessity. Note that even
most use phobes can't stand to dot operator names, so at the
very least you need the tool that allows you to click on an
operator name and find out where the operator is defined.

Note that many people can't stand to put the full package names
on the dots anyway, so you get notations like

   CT.List

instead of Compressed_Tree.List

Now you have to first find CT to know where things are. How
will you find CT? Well you use some tool. Perhaps you use some
decrepit tool like the search of an editor. But it would be
better to use the click and find procedure even for CT if you
have decent tools. If you have these decent tools, then you
might as well click on List and get where you really want to
go.

I am sorry Ted has to deal with such a decrepit environment that
the challenge of finding out where a variable is defined makes
him reach for the baseball bat, but I am not at all sure that
we should condition our style on the limitations of such
environments.

The decision to use or not use USE clauses should be based on
what makes the code clearer, not on entirely unreasonable and
unnecessary limitations of tool sets.

Probably the majority of Ada programmers fall between the ALWAYS
and NEVER use groups, and instead take a reasonable approach of
using USE where appropriate, and not using it where it is not
helpful.

Robert Dewar


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Robert A Duff]

Richard D Riehle <laoXhai@ix.netcom.com> writes:

>      package Sweet_Tooth is
> 
>         type Frozen_Dessert is private;
>         type Lollipop is (OrangeIce, Fudgecicle, Chocolate_Cream);
> 
>         Procedure Create (F : in out Frozen_Dessert);
>         -- more operations
>         -- declare an Operators only package
>         package Ops is
>            function "=" (L, R : Lollipop) return Boolean
>                                        renames Sweet_Tooth."=";
>            function ">" (L, R : Lollipop) return Boolean
>                                        renames Sweet_Tooth.">";

I used to like this idea, but I've seen nasty bugs caused by it.
Imagine if that last ">" were replaced with "=" due to a cut-and-paste
error.  It's hard to notice such a bug by reading the code, because as
soon as you see "package Ops is" followed by "function ">"", you already
know (or *think* you know) what comes next, so you don't read it
carefully.  And when you're reading someplace else that calls "<", you
obviously think it's calling something called "<".

The "use type" clause is safer.

> This package has the advantage of exporting, through a use clause, only
> the operators you want unless you decide to make others explicitly
> visible.  The client of the package has an easy way to achieve the
> necessary visibility.   It is a better option than use type because it
> only makes visible a restricted set of operators.

Good point.  I wouldn't mind having a concise way of saying (eg) "T is
an integer type with just "+" and "-" operators.  But I still prefer
"use type" to "package Ops".

>...   Also, it allows one
> to design new behavior for some operators while implementing others
> through a simple renames clause.

It seems like a dangerous idea to use anything *but* a renaming, if the
operator in question is predefined.  I mean, if Sweet_Tooth."=" and
Sweet_Tooth.Ops."=" do two different things, you're asking for trouble.
Maybe I misunderstood what you mean, here.

>...  With Ada 95 you could create a child package for Sweet_Tooth.Ops 
> to keep it extensible. 

I don't understand that point.

> Ada's use clause, like the #include of the C family of languages,
> is somewhat analogous to wiring your home with uninsulated cable.

That analogy is a bit overblown!  If you want to insulate something, put
it in a package body where it belongs.  And surely "use" is not in the
same category as "#include".

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Elimination of "use" clauses

[Richard D Riehle]

I always enjoy the thoughtful responses posted here by Dr. Duff.  

In article <wccr9mc5y47.fsf@world.std.com>,
	Robert A Duff <bobduff@world.std.com> wrote:

in response to my advocacy of a nested or child Ops package (see the code 
moved to the end of this posting)

>I used to like this idea, but I've seen nasty bugs caused by it.
>Imagine if that last ">" were replaced with "=" due to a cut-and-paste
>error.  It's hard to notice such a bug by reading the code, because as
>soon as you see "package Ops is" followed by "function ">"", you already
>know (or *think* you know) what comes next, so you don't read it
>carefully.  And when you're reading someplace else that calls "<", you
>obviously think it's calling something called "<".

 Cut and paste errors are one of the inherent problems with
 renaming, especially a liberal model for renaming.  I agree
 that one must be careful about such things.  More frequently,
 I have seen people use ">" when then intended "<".  This error
 is still possible with "use type".  If one only exports the "<",
 the chance of making a mistake of ">" is reduced.  

>The "use type" clause is safer.

Respectfully disagree.  The use type clause exports visibility
for every operator on a type.  Now, if use type allowed a list of the
operators to be restricted ...    For example, 

        use type X.T ("=", "<", "/");

one would be able to designate exactly which operators were appropriate
to the use of the type.  This is analogous to the "export" directive
found in some other languages.

>> This package has the advantage of exporting, through a use clause, only
>> the operators you want unless you decide to make others explicitly
>> visible.  The client of the package has an easy way to achieve the
>> necessary visibility.   It is a better option than use type because it
>> only makes visible a restricted set of operators.
>
>Good point.  I wouldn't mind having a concise way of saying (eg) "T is
>an integer type with just "+" and "-" operators.  But I still prefer
>"use type" to "package Ops".

We agree up to a certain point.  Explicit export directives would 
solve the problem, but that is not currently part of Ada.  Again,
"use type" is too broad, I think.  

>>...   Also, it allows one
>> to design new behavior for some operators while implementing others
>> through a simple renames clause.
>
>It seems like a dangerous idea to use anything *but* a renaming, if the
>operator in question is predefined.  I mean, if Sweet_Tooth."=" and
>Sweet_Tooth.Ops."=" do two different things, you're asking for trouble.
>Maybe I misunderstood what you mean, here.

The example that comes to mind is the division operator on a floating
point value.  Instead of implementing it via a renames in package 
Sweet_Tooth.Ops, I might want to design my own "/" which does additional
checking of the values, raises some specialized exception, takes into
account a set of tolerable ranges instead of behaving exactly as 
defined in the language or numerics annex.   The same could be true
of other arithmetic operators.  Also, the "=" operator on a floating
point might be designed to greater tolerances than predefined by the
language.  

>>...  With Ada 95 you could create a child package for Sweet_Tooth.Ops 
>> to keep it extensible. 

>I don't understand that point.

This simply means that Sweet_Tooth.Ops could be a child package of
Sweet_Tooth instead of a nested package.  In that case, it is extensible
with new operators as necessary.

>> Ada's use clause, like the #include of the C family of languages,
>> is somewhat analogous to wiring your home with uninsulated cable.
>
>That analogy is a bit overblown!  If you want to insulate something, put
>it in a package body where it belongs.  And surely "use" is not in the
>same category as "#include".

Analogies always have their flaws.  The suggestion of putting the 
entity into the package body is, I agree, the ideal.  If this were
Modula-3, that would solve the problem quite nicely.  Since Ada is not
designed to explicitly support opaque types, one must often use
indirection to support this notion.  

When a "with" and "use" are used together, it is very much like 
removing the insulation.  Although it is not quite as dangerous as
the C++ #include, it is very close to it.   To be sure, we still
have all the issues of type conformity, semantic legalities, etc.,
but we also have the problem of excessive visibility.  One of Ada's
most positive strengths, as a software engineering language, is the
separation of scope and visibility.   Perhaps what is needed, in the
next revision, is some additional syntax for making this feature even
stronger.  Maybe we really do need some kind of "export" feature so
the designer of a package can be explicit about what should be allowed
and what should not be.   Meanwhile, the nested or child Ops package,
properly designed, provides that level of control.  I think it does so
better than the "use type" since it restricts the set of operators 
available via any use clause.  

Richard Riehle
richard@adaworks.com
http://www.adaworks.com

-- =========== Original Code for this Discussion ================

>Richard D Riehle <laoXhai@ix.netcom.com> writes:
>
>>      package Sweet_Tooth is
>> 
>>         type Frozen_Dessert is private;
>>         type Lollipop is (OrangeIce, Fudgecicle, Chocolate_Cream);
>> 
>>         Procedure Create (F : in out Frozen_Dessert);
>>         -- more operations
>>         -- declare an Operators only package
>>         package Ops is
>>            function "=" (L, R : Lollipop) return Boolean
>>                                        renames Sweet_Tooth."=";
>>            function ">" (L, R : Lollipop) return Boolean
>>                                        renames Sweet_Tooth.">";
>>         end Ops;

Re: Elimination of "use" clauses

[Dale Stanbrough]

Richard D Riehle wrote:

" >Good point.  I wouldn't mind having a concise way of saying (eg) "T is
  >an integer type with just "+" and "-" operators.  But I still prefer
  >"use type" to "package Ops".
  
  We agree up to a certain point.  Explicit export directives would 
  solve the problem, but that is not currently part of Ada.  Again,
  "use type" is too broad, I think.  "


Export directives -could- do it (and it is not a bad idea at all),
but we shouldn't forget that Ada already has the ability to export
-just- the operators we want, and it's called using a private type
and only advertising the appropriate operations.

However this has the disadvantage that you can't use the private
type in all the places that you might want to use an integer type.

Dale

Re: Elimination of "use" clauses

[Richard D Riehle]

In article <dale-1807991510420001@192.168.0.2>,
	dale@cs.rmit.edu.au (Dale Stanbrough) wrote:

>Export directives -could- do it (and it is not a bad idea at all),
>but we shouldn't forget that Ada already has the ability to export
>-just- the operators we want, and it's called using a private type
>and only advertising the appropriate operations.

I fully agree that the private type is underused for this purpose.
However, you will need to declare the arithmetic and logical 
operators for a private type.  This is the ideal place for using
a nested Ops package to restrict the set of operators to exactly
those you want available in your design.

package P is
   type T is private;
   -- operations on T
   package Ops is
     function ">" (L, R : T) return Boolean;
     function "+" (L, R : T) return T;
   end Ops;
end P;

Now, use P.Ops makes sense and exports only the operators the 
designer feels are appropriate but still restricts them to an
Ops package.  Of course, if they were not in the nested Ops package,
one could still invoke the "use type" clause.  In the end, I think it
it will be a matter of preference rather than a matter of which is
better.

>However this has the disadvantage that you can't use the private
>type in all the places that you might want to use an integer type.

 That is  exactly the point.  We need to explicitly define the operators
 for the private type so it is not exactly like a free integer.

Richard Riehle
richard@adaworks.com
http://www.adaworks.com
 

Re: Elimination of "use" clauses

[Brian Rogoff]

On Tue, 20 Jul 1999, Richard D Riehle wrote:
> In article <dale-1807991510420001@192.168.0.2>,
> 	dale@cs.rmit.edu.au (Dale Stanbrough) wrote:
> 
> >Export directives -could- do it (and it is not a bad idea at all),
> >but we shouldn't forget that Ada already has the ability to export
> >-just- the operators we want, and it's called using a private type
> >and only advertising the appropriate operations.
> 
> I fully agree that the private type is underused for this purpose.
> However, you will need to declare the arithmetic and logical 
> operators for a private type.  This is the ideal place for using
> a nested Ops package to restrict the set of operators to exactly
> those you want available in your design.

If you don't mind making the client refuse to look at things he doesn't
want to see, rather than making the provider hide what he doesn't want to
show, generic signature packages could also be used in these situations. 

I still really dislike "use type". 

-- Brian

Re: Elimination of "use" clauses

[Robert Dewar]

In article > I still really dislike "use type".

Why? You have not clearly stated a reason for this dislike!

And I certainly have not seen any satisfactory substitute
proposed!


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Brian Rogoff]

On Tue, 20 Jul 1999, Robert Dewar wrote:

> In article > I still really dislike "use type".
> 
> Why? You have not clearly stated a reason for this dislike!

They are unnecessary, add no expressive power to Ada, and will look really
ugly if (when?) "with type" is added to fix the mutually recursive package 
spec problem. I find the idea of "special casing" the operators inelegant; 
if anything I'd prefer that operators and functions were more alike and
that one could define new infix operators. 

> And I certainly have not seen any satisfactory substitute
> proposed!

Regular "use" clauses, inside of declarative regions to limit their scope
if one is worried about not being able to tell where a definition comes
from. I am not a use-phobe, though I understand that one should be careful 
with use clauses (and aliasing, and overloading, and access types, etc.)

-- Brian

Re: Elimination of "use" clauses

[Robert Dewar]

In article
<Pine.BSF.4.10.9907201840120.500-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> Regular "use" clauses, inside of declarative regions to limit
their scope
> if one is worried about not being able to tell where a
definition comes
> from. I am not a use-phobe, though I understand that one
should be careful
> with use clauses (and aliasing, and overloading, and access
types, etc.)


OK, that's reasonable. But you have to realize that use type
was introduced into the language SPECIFICALLY for people who
reject the above solution. Since there are MANY such people,
there was a strong constituency for this feature. I regard it
as useless since I am quite content to use USE, but there are
many Ada programmers adamantaly opposed to even your limited
acceptable of use clauses.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Brian Rogoff]

On Wed, 21 Jul 1999, Robert Dewar wrote:
> In article
> <Pine.BSF.4.10.9907201840120.500-100000@shell5.ba.best.com>,
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > Regular "use" clauses, inside of declarative regions to limit
> their scope
> > if one is worried about not being able to tell where a
> definition comes
> > from. I am not a use-phobe, though I understand that one
> should be careful
> > with use clauses (and aliasing, and overloading, and access
> types, etc.)
> 
> 
> OK, that's reasonable. But you have to realize that use type
> was introduced into the language SPECIFICALLY for people who
> reject the above solution. Since there are MANY such people,
> there was a strong constituency for this feature. I regard it
> as useless since I am quite content to use USE, but there are
> many Ada programmers adamantaly opposed to even your limited
> acceptable of use clauses.

I'm not fond of this aspect of the language design process, since there
are features that I think add something to the expressiveness of the
language which were omitted because strong constituencies abhorred them.
Also, Tucker Taft must have liked this enough to include it, so he really
is to blame. It wasn't designed by committee, you know :-). 

-- Brian

Re: Elimination of "use" clauses

[Robert Dewar]

In article
<Pine.BSF.4.10.9907211854070.23477-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> I'm not fond of this aspect of the language design process,
since there
> are features that I think add something to the expressiveness
of the
> language which were omitted because strong constituencies
abhorred them.


Well you seem to be saying that

a) I am not fond of the fact that useful features that I would
have liked have been omitted from the language. They should
have payed more attention to people like me.

b) I don't like the process whereby they pay attention to what
people think, and follow these recommendations

:-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Brian Rogoff]

On Thu, 22 Jul 1999, Robert Dewar wrote:
> In article
> <Pine.BSF.4.10.9907211854070.23477-100000@shell5.ba.best.com>,
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > I'm not fond of this aspect of the language design process,
> since there
> > are features that I think add something to the expressiveness
> of the
> > language which were omitted because strong constituencies
> abhorred them.
> 
> 
> Well you seem to be saying that
> 
> a) I am not fond of the fact that useful features that I would
> have liked have been omitted from the language. They should
> have payed more attention to people like me.

Exactly!! 
 
> b) I don't like the process whereby they pay attention to what
> people think, and follow these recommendations

No, its just that the wrong people are being paid attention to. :-)

-- Brian

Re: Elimination of "use" clauses

[Robert Dewar]

In article
<Pine.BSF.4.10.9907211854070.23477-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
since there
> are features that I think add something to the expressiveness
of the
> language which were omitted

care to give examples??


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Brian Rogoff]

On Thu, 22 Jul 1999, Robert Dewar wrote:
> In article
> <Pine.BSF.4.10.9907211854070.23477-100000@shell5.ba.best.com>,
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> since there
> > are features that I think add something to the expressiveness
> of the
> > language which were omitted
> 
> care to give examples??

I could, but there's this guy who frequents c.l.a. who gets annoyed at 
stuff that has been beaten to death before being recycled again and 
again, with no new information added, so in deference to this fellow, I'll
let the thread die, and refer readers to DejaNews :-). 

-- Brian

PS: my two biggest peeves are out mode function params and downward
    funargs. I'd have been satisfied with Bob Duffs limited access to 
    subprogram but I know you wouldn't have. There are quite a few other 
    things too but those are fairly simple ones that I frequently miss. 

Re: Elimination of "use" clauses

[Ted Dennison]

In article <Pine.BSF.4.10.9907201840120.500-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> On Tue, 20 Jul 1999, Robert Dewar wrote:
> spec problem. I find the idea of "special casing" the operators
inelegant;
> if anything I'd prefer that operators and functions were more alike
and
> that one could define new infix operators.

But they are *already* a special case, which is the source of the
problem. Unline nomal functions, the infix operators can no longer be
used in their expected manner (infix) when they are not directly
visible. If the following worked:
   with FooBar;
   ...
      Foo FooBar.= Bar

...then perhaps we wouldn't be having this discussion.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Robert Dewar]

In article <7n4r4e$5p$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
>       Foo FooBar.= Bar

Yech! this is even worse than the prefix notation if you ask
me. I very much doubt that this construction (which is by the
way syntactically dubious) would satisfy those people for whom
use type is a welcome way out of renaming or using prefix
notation.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Robert A Duff]

Ted Dennison <dennison@telepath.com> writes:

> visible. If the following worked:
>    with FooBar;
>    ...
>       Foo FooBar.= Bar
> 
> ...then perhaps we wouldn't be having this discussion.

If that were allowed by the standard (assuming you could figure out how
to parse it), I would forbid it in my project standards.  It defeats the
whole purpose of using operator symbols, just as badly as
Foo_Bar."="(Foo, Bar).

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Elimination of "use" clauses

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> In article > I still really dislike "use type".
> 
> Why? You have not clearly stated a reason for this dislike!
> 
> And I certainly have not seen any satisfactory substitute
> proposed!

Remember the original proposal of the design team was to make the
operators visible by default -- you would get the "use type" behavior
without writing *anything* extra.

This idea was rejected primarily due to upward compatibility concerns,
although I think there were some reviewers who just didn't like it (just
as some folks here don't like "use type").

I understand the upward compatibility concern, but it really is odd that
in Ada ":=" is visible everywhere, but "=" is not.  "In" and "not in"
are visible everywhere, but "not" is not.  I imagine the reasoning of
the original design team had to do with which operators are "operators"
(in Ada jargon) -- ie user-definable.  But that seems like a pretty weak
reason, when I normally just want to use the predefined ones.

Robert is fond of saying that style rules shouldn't be absolute.  Well,
I usually agree, but here's one that I think really is absolute: Never,
never use dotted notation in a function call if the function name is an
operator symbol.  If you have something that really needs to be
distinguished that carefully, then you shouldn't give it a name like
"+".  Can anybody think of an example that shows I'm wrong?

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Elimination of "use" clauses

[Michael F. Yoder]

Robert A Duff wrote:
> Robert is fond of saying that style rules shouldn't be absolute.  Well,
> I usually agree, but here's one that I think really is absolute: Never,
> never use dotted notation in a function call if the function name is an
> operator symbol.  If you have something that really needs to be
> distinguished that carefully, then you shouldn't give it a name like
> "+".  Can anybody think of an example that shows I'm wrong?

How contrived and lame an example will you admit?  :-)

I'm pretty sure I have some black-box tests somewhere that work as
follows.  There's a package P to be tested that declares some
operators.  Within the black-box test, I declare a package Q that
contains identically named operators which implement exactly the same
functions; but these use crude and simple (and hopefully obviously
correct) methods.  Then the test contains code something like this:

   for <lots of values of L and R> loop
      Assert(P."+"(L, R) = Q."+"(L, R), "+ is wrong");
      Assert(P."-"(L, R) = Q."-"(L, R), "- is wrong");
      -- etc.
   end loop;

The selection notation is needed because the operators are homographs
and both are used at the same time.  Now if this weren't allowed I could
have made the operators in Q use a derived type, and added type
conversions at appropriate spots.  But I only thought of this method
because you were threatening to make it necessary.  :-)

-- 
----
Michael Yoder

Re: Elimination of "use" clauses

[Robert A Duff]

"Michael F. Yoder" <yoder@decada.zko.dec.com> writes:

> How contrived and lame an example will you admit?  :-)
...
>    for <lots of values of L and R> loop
>       Assert(P."+"(L, R) = Q."+"(L, R), "+ is wrong");
>       Assert(P."-"(L, R) = Q."-"(L, R), "- is wrong");
>       -- etc.
>    end loop;

OK, you win.


It occurs to me that "=" might be redefined, too!
How do you like this:

       Assert(P."="(P."+"(L, R), Q."+"(L, R))
	    = Q."="(P."+"(L, R), Q."+"(L, R)), "something is wrong");
            ^ That's the equal on two Booleans, returning Boolean.

;-) ;-)

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Elimination of "use" clauses

[Tucker Taft]

Richard D Riehle wrote:
> 
> In article <dale-1807991510420001@192.168.0.2>,
>         dale@cs.rmit.edu.au (Dale Stanbrough) wrote:
> 
> >Export directives -could- do it (and it is not a bad idea at all),
> >but we shouldn't forget that Ada already has the ability to export
> >-just- the operators we want, and it's called using a private type
> >and only advertising the appropriate operations.
> 
> I fully agree that the private type is underused for this purpose.
> However, you will need to declare the arithmetic and logical
> operators for a private type.  This is the ideal place for using
> a nested Ops package to restrict the set of operators to exactly
> those you want available in your design.
> 
> package P is
>    type T is private;
>    -- operations on T
>    package Ops is
>      function ">" (L, R : T) return Boolean;
>      function "+" (L, R : T) return T;
>    end Ops;
> end P;
> 
> Now, use P.Ops makes sense and exports only the operators the
> designer feels are appropriate but still restricts them to an
> Ops package.  Of course, if they were not in the nested Ops package,
> one could still invoke the "use type" clause.  In the end, I think it
> it will be a matter of preference rather than a matter of which is
> better.

The major difference is that the operators are no longer inherited
as part of a derived type definition.

In general, the "ops" package idiom was an Ada 83 work-around.
Now that we have use-type, I recommend against proliferating it further.

There are ways to work with a language, and ways to fight against it.
In Ada 95, the "use type" is definitely the language-defined way to
deal with operator visibility.  In Ada 83, there really wasn't
any particularly good language support for operator visibility,
so various approaches were adopted.

> ...
> Richard Riehle
> richard@adaworks.com
> http://www.adaworks.com
> 

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Elimination of "use" clauses

[Richard D Riehle]

In article <3798E50D.100976B@averstar.com>,
	Tucker Taft <stt@averstar.com> wrote:

>Richard D Riehle wrote:

 -- Richard's code appended to end of this article to avoid length example

>The major difference is that the operators are no longer inherited
>as part of a derived type definition.

 I understand that the inheritance disappears.  For the kind of situations
 involved, that may not be a real problem.  

>In general, the "ops" package idiom was an Ada 83 work-around.
>Now that we have use-type, I recommend against proliferating it further.

 Yes, the "ops" package was a work-around.  A very good one, it turns out.
 Even with its drawbacks, and there are some, the question is whether it is
 better to export all the operators on a type or only some.  The idea of
 making a type "private" and declaring the operators was suggested and that
 is also a good solution.  However, for an enumerated type, this is not a
 good solution.  Sometimes I only want an equality operator available on an
 enumerated type Should I require the client to rename it or should I export it
 in some explicit way.  I would prefer an explicit export that targets only
 the operators I want the client to have.  The "use type", while often useful,
 may export more than I want.   

>There are ways to work with a language, and ways to fight against it.
>In Ada 95, the "use type" is definitely the language-defined way to
>deal with operator visibility.  In Ada 83, there really wasn't
>any particularly good language support for operator visibility,
>so various approaches were adopted.

 I don't consider the "ops" package as a way to "fight" against the language.
 It is simply an alternative that sometimes makes sense.  The naked use clause,
 the "use type", the renaming of operators, are all other alternatives that
 sometimes make sense.  A designer must decide which option is most appropriate
 for the solution.   I am pretty certain we do not disagree on this.

 Richard

>> ...
>> Richard Riehle
>> richard@adaworks.com
>> http://www.adaworks.com

-- ======================= Original Example Appended Here =======================
>> 
>> I fully agree that the private type is underused for this purpose.
>> However, you will need to declare the arithmetic and logical
>> operators for a private type.  This is the ideal place for using
>> a nested Ops package to restrict the set of operators to exactly
>> those you want available in your design.
>> 
>> package P is
 
>>    type T is private;
>>    -- operations on T
>>    package Ops is
>>      function ">" (L, R : T) return Boolean;
>>      function "+" (L, R : T) return T;
>>    end Ops;
>> end P;
>> 
>> Now, use P.Ops makes sense and exports only the operators the
>> designer feels are appropriate but still restricts them to an
>> Ops package.  Of course, if they were not in the nested Ops package,
>> one could still invoke the "use type" clause.  In the end, I think it
>> it will be a matter of preference rather than a matter of which is
>> better.

Re: Elimination of "use" clauses

[David Kristola]

dale@cs.rmit.edu.au (Dale Stanbrough) writes:
>Richard D Riehle wrote:
>
>" >Good point.  I wouldn't mind having a concise way of saying (eg) "T is
>  >an integer type with just "+" and "-" operators.  But I still prefer
>  >"use type" to "package Ops".
>  
>  We agree up to a certain point.  Explicit export directives would 
>  solve the problem, but that is not currently part of Ada.  Again,
>  "use type" is too broad, I think.  "
>
>
>Export directives -could- do it (and it is not a bad idea at all),
>but we shouldn't forget that Ada already has the ability to export
>-just- the operators we want, and it's called using a private type
>and only advertising the appropriate operations.
>
>However this has the disadvantage that you can't use the private
>type in all the places that you might want to use an integer type.
>
>Dale

Can't "abstract" be used to remove the unwanted operators from
the original package?

function "*"(Left, Right : T) is abstract; -- eliminate multiplication


--djk, keeper of arcane lore & trivial fluff
Home: David95037 at aol dot com
Spam: goto.hades@welovespam.com

Re: Elimination of "use" clauses

[jerry]

Richard D Riehle <laoXhai@ix.netcom.com> wrote:

: Modula-3, that would solve the problem quite nicely.  Since Ada is not
: designed to explicitly support opaque types, one must often use
: indirection to support this notion.  

I am unfamiliar with the term 'opaque type', perhaps because I never looked
at Modula-3. Can you explain what it means ?

-- 
-- Jerry van Dijk | Leiden, Holland
-- Team Ada       | jdijk@acm.org
-- see http://stad.dsl.nl/~jvandyk

Re: Elimination of "use" clauses

[Vladimir Olensky]

jerry@jvdsys.stuyts.nl wrote in message ...
>Richard D Riehle <laoXhai@ix.netcom.com> wrote:
>
>: Modula-3, that would solve the problem quite nicely.  Since Ada is not
>: designed to explicitly support opaque types, one must often use
>: indirection to support this notion.
>
>I am unfamiliar with the term 'opaque type', perhaps because I never looked
>at Modula-3. Can you explain what it means ?
>
>--
>-- Jerry van Dijk | Leiden, Holland
>-- Team Ada       | jdijk@acm.org
>-- see http://stad.dsl.nl/~jvandyk

Have a look at
 http://www.research.digital.com/SRC/m3defn/html/opaques.html#idx.129

Nice article about usage of M3 opaque types  is available at
   http://www.research.digital.com/SRC/modula-3/html/partial-rev/index.html

Regards,
Vladimir Olensky

Re: Elimination of "use" clauses

[Richard D Riehle]

In article <FF2ECA.76@stuyts.nl>,
	jerry@jvdsys.stuyts.nl wrote:

>I am unfamiliar with the term 'opaque type', perhaps because I never looked
>at Modula-3. Can you explain what it means ?

I will answer this question with the warning that my examples
are simply a repetition of already well-known coding practices. 
Also, even though the Ada code will seem slightly longer than
the Modula-3, there are good reasons to prefer the Ada.  Even
so, the ease of creating opaque types in Modula-3 is an attractive
features of that language.

An "opaque type" is a type in which all the details of the type are
encapsulated in an implementation part of a module.  This is required
in Modula-3.  Ada allows us to promote some of the definition to the
private part of the specification.   Ada also allows us to defer the
details to the pacakge body. 

The opaque type is commonly used in Modula-3 where we would use a [limited]
private type in Ada.  

The Modula-3 equivalent of a package specification is now called 
the INTERFACE and equivalent of the package body is called
a MODULE.  Modula-3 does not have a private part in the INTERFACE.
Consider classic generic Stack example in  Modula-3,

GENERIC INTERFACE Stack (SomeElementType);
  TYPE Stack_Type <: REFANY;
  (* procedures for push and pop);
END Stack;

GENERIC MODULE Stack(SomeElementType);
 REVEAL Stack_Type = more details for the stack type
 implementation of push, pop, etc.
END Stack;

My appreciation to MODULA-3 experts who might notice some syntatic
error in my example.  The REVEAL command gives the full definition of
the type from the INTERFACE.
 
In Ada, a generic stack might be designed several ways. We first show the
common textbook example. 

generic
  type StackElementType is private;
  Max  : Positive := 100;
package Stack is
  type Stack_Type is limited private;
  -- declarations for push, pop, etc.
private
  type Stack_Array is array(Positive range <>) of StackElementType;
  type Stack is record
     Top : Natural := 0;
     Data : Stack_Array(1..Max);
  end record;
end Stack;
 
In this example, the private part contains all the information about 
the structure of the stack.  The second Ada example is designed as an 
"opaque type".  

generic
  type StackElementType is private;
  Max  : Positive := 100;
package Stack is
  type Stack_Type is limited private;
  -- declarations for push, pop, etc.
private
  type Stack_Data;
  type Stack is access all Stack_Data;  
end Stack;

where there is no information about the structure of the stack,
even in the private part.  The details of the stack are deferred
to the package body.  For example,

package body Stack is
  type Stack_Array is array(1..Max) of StackElementType;
  subtype Stack_Index is range 0..Max;
  type Stack_Item is record
    Top : Stack_Index := 0;
    Data : Stack_Array;
  end record;
  -- implement push, pop, etc. 
end Stack;

Richard Riehle
richard@adaworks.com
http://www.adaworks.com

Opaque Types (was Elimination of "use" clauses)

[David C. Hoos, Sr.]

Richard D Riehle <laoXhai@ix.netcom.com> wrote in message
news:7n0hr7$180@dfw-ixnews21.ix.netcom.com...
> In article <FF2ECA.76@stuyts.nl>,
> jerry@jvdsys.stuyts.nl wrote:
>
> >I am unfamiliar with the term 'opaque type', perhaps because I never
looked
> >at Modula-3. Can you explain what it means ?
>
<large snip>
> The second Ada example is designed as an
> "opaque type".
>
> generic
>   type StackElementType is private;
>   Max  : Positive := 100;
> package Stack is
>   type Stack_Type is limited private;
>   -- declarations for push, pop, etc.
> private
>   type Stack_Data;
>   type Stack is access all Stack_Data;
> end Stack;
>
> where there is no information about the structure of the stack,
> even in the private part.  The details of the stack are deferred
> to the package body.  For example,
>
> package body Stack is
>   type Stack_Array is array(1..Max) of StackElementType;
>   subtype Stack_Index is range 0..Max;
>   type Stack_Item is record
>     Top : Stack_Index := 0;
>     Data : Stack_Array;
>   end record;
>   -- implement push, pop, etc.
> end Stack;
>

Didn't you mean something more like the following?
(The type declared in the body is not a completion of the
incomplete type Stack declared in the private part).

generic
  type StackElementType is private;
  Max  : Positive := 100;
package Stack is
  type Stack_Type is limited private;
  -- declarations for push, pop, etc.
private
  type Stack_Item;
  type Stack_Type is access all Stack_Item;
end Stack;

package body Stack is
  type Stack_Array is array(1..Max) of StackElementType;
  subtype Stack_Index is Integer range 0 .. Max;
  type Stack_Item is record
    Top : Stack_Index := 0;
    Data : Stack_Array;
  end record;
  -- implement push, pop, etc.
end Stack;

That asked, I now have another question, or two, viz.:

  1. Is the value of an opaque type worth giving up the
     flexibility of a discriminated type wherein the
     stack size does not need to be a formal parameter
     of the generic package, or have I missed a way to
     have a discriminated opaque type?

  2. In a similar vein, it seems that opaque controlled
     types are not possible.  Is this true.

Perhaps a more general question is -- is there really
any value in making a limited private type opaque?  If so,
what is that advantage?

David C. Hoos, Sr.

Re: Elimination of "use" clauses

[jerry]

Richard D Riehle <laoXhai@ix.netcom.com> wrote:

:>I am unfamiliar with the term 'opaque type', perhaps because I never looked
:>at Modula-3. Can you explain what it means ?

: An "opaque type" is a type in which all the details of the type are
: encapsulated in an implementation part of a module.  This is required
: in Modula-3.  Ada allows us to promote some of the definition to the
: private part of the specification.   Ada also allows us to defer the
: details to the pacakge body. 

: In this example, the private part contains all the information about 
: the structure of the stack.  The second Ada example is designed as an 
: "opaque type".  

Aha, yes I can see where the term comes from. Although I didn't know it,
I have been a heavy user of opaque types in cases where I wanted to hide
as much as possible of the actual implementation of the type from the user.

Actually, I thought of this of two styles of programming:

a) use the package body for only the implementation (i.e. functions and
   procedures), keep every else as much as possible in the spec. This
   keeps the body concentrated on the implementation, without being
   'distracted' by a lot of deferred definition. Advantages are, IHMO,
   easier testing. easier finding definitions. It also seems to be in
   the Ada spirit.
   
However, I sometimes feel unconfortable with this approach, switching to
the other style (where Ada allows it):

b) use the spec for exporting only information that the client program
   needs, moving as much as possible to the package body. The advantage
   is a better encapsulation (hmmm, ok, information hiding). Also usually
   less inpact when changing some small details.

As an old dutch proverb says: 'being consistent is develish', I tend to
use both styles. Style b) for things like a File_IO package that has to
run on both NT and Linux: single spec, multiple bodies. Style a) for database
implementations as these are not directly used by the client of the
database package itself.

-- 
-- Jerry van Dijk | Leiden, Holland
-- Team Ada       | jdijk@acm.org
-- see http://stad.dsl.nl/~jvandyk

Re: Elimination of "use" clauses

[Ted Dennison]

In article <7mrjus$bet@dfw-ixnews14.ix.netcom.com>,
  Richard D Riehle <laoXhai@ix.netcom.com> wrote:

> for every operator on a type.  Now, if use type allowed a list of the
> operators to be restricted ...    For example,
>
>         use type X.T ("=", "<", "/");
>
> one would be able to designate exactly which operators were
appropriate

Ohhhhh. I *like* that idea. Currently "use type" seems a bit sloppy.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Tucker Taft]

Ted Dennison wrote:
> 
> In article <7mrjus$bet@dfw-ixnews14.ix.netcom.com>,
>   Richard D Riehle <laoXhai@ix.netcom.com> wrote:
> 
> > for every operator on a type.  Now, if use type allowed a list of the
> > operators to be restricted ...    For example,
> >
> >         use type X.T ("=", "<", "/");
> >
> > one would be able to designate exactly which operators were
> appropriate
> 
> Ohhhhh. I *like* that idea. Currently "use type" seems a bit sloppy.

Oh dear, to each his own.

It seems strange that you are deciding at the point of use which
operators are "appropriate."  If there are inappropriate operators,
they shouldn't be declared in the package, and shouldn't be primitive.
I can't think of a type where "<" is appropriate but ">" is not.
Can you give a realistic example?  This seems like overkill,
IMHO.

> T.E.D.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Elimination of "use" clauses

[Ted Dennison]

In article <37934672.E401493E@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> Ted Dennison wrote:

> > Ohhhhh. I *like* that idea. Currently "use type" seems a bit sloppy.
>
> I can't think of a type where "<" is appropriate but ">" is not.
> Can you give a realistic example?  This seems like overkill,
> IMHO.

Well...no.

My angle on this was that as a developer I much prefer explicitly
stating what I'm getting from where. Using full dot notation for
packages is part of that. In the case of "use type", I'd feel a lot
better saying which routines I need, rather that using a construct that
in effect says, "give me all the operations, whatever they may be."

But you are right. I can't think of a good example where getting "="
would be fine, but I don't want "-". Perhaps my Modula-2 bias is just
acting up again. (I'd better get that checked...)

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Ed Falis]

In article <7ligdq$c8q$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:


> While I appreciate the fact that *some* compiler systems have facilites
> to help decipher stuff like this under *certian* circumstances, I am not
> persuaded that obtuse source code is just a "tool problem".
>
> If I have to use specialized tools to figure out what someone's source
> code is doing, the tool that springs most readily to mind is a baseball
> bat...

Aside from the fact that using a compiler system that doesn't provide this
kind of capability is a bit obtuse these days,	I'd have to say that I find
code cluttered with extra identifiers and so on more than code that makes use
of context with disambiguation where necessary.  If the namespace within a
unit requires selected notation to be understandable, there's a good chance
the sucker is much too big.

I've been doing some pretty serious programming in Eiffel lately, with a fair
amount of multiple inheritance.  The language doesn't use anything like
selected notation, and doesn't even have explicit context clauses.  But with
decent browsing available, I never miss them at all.  And I mainly use the
browsing just to look at interfaces.  The code tends to be clean and
understandable, with a clear structure.  This is not a language-specific
issue.	It's a matter of how one does things, and of standardized
expectations (as Robert is also inclined to say).


- Ed Falis
Aonix


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Ed Falis]

In article <7lh74s$v36$1@nnrp1.deja.com>,
  Robert Dewar <dewar@gnat.com> wrote:


> I don't know of a dotification tool, but it seems strange to
> claim that it is difficult and time-consuming to find out
> which package a procedure is from. That sounds like you are
> not using appropriate tools. Try using the EMACS interface
> to GNAT, and you can immediately go from any identifier to
> the declaration (and the proper package in which this
> declaration appears). This is actually much more useful in
> reading code, since you immediately find out not only what
> package the identifier is in, but you go to the declaration
> which shows you the details of what the identifier means.
>
> There are other tools that have this same capability. This
> seems pretty important functionality. There is also the gnatfind
> utility available with GNAT for providing this same kind of
> information in command line mode.

I have to agree (strongly) with this comment.  There's little reason these
days not to use such a browsing capability.  This allows you to take
advantage of the benefit of use clauses:  uncluttering the source text so you
can easily understand it logic and structure.  With resolution of references
a click or two away, there's little excuse for long dotted-notation
references.

- Ed Falis
Aonix


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Joe Wisniewski]

Ed Falis wrote in message <7lj9lb$mos$1@nnrp1.deja.com>...
>In article <7lh74s$v36$1@nnrp1.deja.com>,
>  Robert Dewar <dewar@gnat.com> wrote:
>
>
>> I don't know of a dotification tool, but it seems strange to
>> claim that it is difficult and time-consuming to find out
>> which package a procedure is from. That sounds like you are
>> not using appropriate tools. Try using the EMACS interface
>> to GNAT, and you can immediately go from any identifier to
>> the declaration (and the proper package in which this
>> declaration appears). This is actually much more useful in
>> reading code, since you immediately find out not only what
>> package the identifier is in, but you go to the declaration
>> which shows you the details of what the identifier means.
>>
>> There are other tools that have this same capability. This
>> seems pretty important functionality. There is also the gnatfind
>> utility available with GNAT for providing this same kind of
>> information in command line mode.
>
>I have to agree (strongly) with this comment.  There's little reason these
>days not to use such a browsing capability.  This allows you to take
>advantage of the benefit of use clauses:  uncluttering the source text so
you
>can easily understand it logic and structure.  With resolution of
references
>a click or two away, there's little excuse for long dotted-notation
>references.
>

   Just a rambling thought or two ....

    Yes and no.Too many organizations still do reviews off of hard-copy.
Yes,
    they should and eventually will do the reviews on line, get comments to
the
    author on line, etc.  In these cases, the author is going to be told to
get
    rid of the use clauses anyway. So, in practice, it is going to be a
while before
    use clauses are accepted.

    Joe
>- Ed Falis
>Aonix
>
>
>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Keith Thompson]

"Joe Wisniewski" <wisniew@acm.org> writes:
[...]
> Just a rambling thought or two ....
> 
> Yes and no.  Too many organizations still do reviews off of
> hard-copy.  Yes, they should and eventually will do the reviews on
> line, get comments to the author on line, etc.  In these cases, the
> author is going to be told to get rid of the use clauses anyway.

At a previous job, we did code reviews from hard-copy.  It enabled us
to get half a dozen or so people sitting around a table, reading the code
and talking about it.

Certainly the technology exists to do the same kind of thing from soft
copy, but realistically most employers aren't willing to deploy the
resources to give everyone net-connected laptops, or to put multiple
PCs in each conference room.  Anything other than face-to-face
discussion (for example, doing code reviews by e-mail) loses the rapid
interaction.

(Of course, there were no use clauses in the C code we were reviewing
-- or, if you prefer, it was full of nasty implicit ones.)

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
One of the great tragedies of ancient history is that Helen of Troy
lived before the invention of the champagne bottle.

Re: Elimination of "use" clauses

[Ed Falis]

In article <931016222.255.99@news.remarQ.com>,
  "Joe Wisniewski" <wisniew@acm.org> wrote:

>
>    Just a rambling thought or two ....
>
>     Yes and no.Too many organizations still do reviews off of hard-copy.
> Yes,
>     they should and eventually will do the reviews on line, get comments to
> the
>     author on line, etc.  In these cases, the author is going to be told to
> get
>     rid of the use clauses anyway. So, in practice, it is going to be a
> while before
>     use clauses are accepted.
>
>     Joe

Which is too bad.  I've seen a lot of atrocities in the name of Ada over the
years.	Common-sense (at least as I define it ;-)  seems not to go around as
much as it ought to.

- Ed


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Elimination of "use" clauses

[Peter Amey]

Ed Falis wrote:

[snip].
> 
> I have to agree (strongly) with this comment.  There's little reason these
> days not to use such a browsing capability.  This allows you to take
> advantage of the benefit of use clauses:  uncluttering the source text so you
> can easily understand it logic and structure.  With resolution of references
> a click or two away, there's little excuse for long dotted-notation
> references.
> 
> - Ed Falis
> Aonix
> 

There seems to be an assumption in parts of this thread that
"dotted.names" = "long.or.unwieldy.dotted.names".  I don't think that
this has to be the case as long as package and other identifier names
are chosen so that they read well when put together with dots (exactly
as I hope we would when choosing record and field names).  A particular
common area of failure in this respect are "bucket" packages containing
type declarations.  For example, if we have:

package BasicTypes is
  type SwitchType is (On, Off, Unknown);
  type ValveType  is (Open, Closed, Unknown);
end BasicTypes;

then variable declarations take the (horrible) form:

X : BasicTypes.ValveType;
Y : BasicTypes.SwitchType;

and expressions using them become (in the absence of use clauses)
become:

if X = BasicTypes.Open and Y = BasicTypes.Off ...


I think this is much better handled by using more, smaller packages
(recognising that switches and valves are different things) thus:

package Switch is
  type T is (On, Off, Unknown);
end Switch;

package Valve is
  type T is (Open, Closed, Unknown);
end Valve;

which leads to the much nicer declarations:

X : Valve.T;
Y : Switch.T;

and expressions of the form:

if X = Valve.Open and Y = Switch.Off ...


I think it is better to choose names that read nicelty in context than
to use extensive renaming (especially abbreviations) to get round
badly-chosen names.  I think this means I agree with Robert about the
need to control the global name space.

regards


Peter


-- 
---------------------------------------------------------------------------   
      __         Peter Amey, Product Manager
        )                    Praxis Critical Systems Ltd
       /                     20, Manvers Street, Bath, BA1 1PX
      / 0        Tel: +44 (0)1225 466991
     (_/         Fax: +44 (0)1225 469006
                 http://www.praxis-cs.co.uk/

--------------------------------------------------------------------------