From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,3dbf2f325f33ce35
X-Google-Attributes: gid103376,public
From: Stephen Leake <Stephen.Leake@gsfc.nasa.gov>
Subject: Re: Elimination of "use" clauses
Date: 1999/07/02
Message-ID: <ubtdvylsh.fsf@gsfc.nasa.gov>#1/1
X-Deja-AN: 496504418
References: <377B5807.88B875E0@cs.york.ac.uk> <7lh74s$v36$1@nnrp1.deja.com>
 <7ligdq$c8q$1@nnrp1.deja.com>
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Newsgroups: comp.lang.ada
Date: 1999-07-02T00:00:00+00:00
List-Id: <comp.lang.ada>

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