Re: Problem with instantiating generic procedure

[Tucker Taft <stt@averstar.com>]

Markus Kuhn wrote:
> The concern about supporting the reader versus the writer is a noble one,
> but it can be wrong to enforce a bit too much here. 

I agree.  It is a tradeoff.  You could argue we erred on
this one.  On the other hand, a systematic naming
convention could make it relatively easy to deal with.

E.g.:

    procedure X_Inst is new G(...);
    procedure X(A, B : Integer) renames X_Inst;

> ...Really readable
> programs can only be achieved with the active cooperation of the writer.

That's certainly true.  On the other hand, I strongly believe that
the design of a language does have a significant effect on the
average readability of code, even when looking at the exact
same pool of programmers.  Languages with a lot of short-hands
to some degree encourage the use of short-hands, which (on the average)
make code harder to read, in my experience.

The goal of Ada is that once the writer succeeded in producing a compilable
program, the meaning is (on the average) quite obvious to the reader.
It does take longer to produce a compilable program, but the clarity
to the subsequent readers makes up for that quickly, in my experience.

> ...
> Where there ever any controlled readability experiments done during the
> Ada design process? I frequently hear that the Pascal syntax style was
> considered to be more readable than the C syntax, but is this just
> folklore or is there a scientifically quotable foundation for this?

The experiments in general involved coding up examples using the competing
proposals, and/or creating "gedanken" experiments relating to maintenance
activities, etc.  Robustness during maintenance activities was also
considered an important criteria.  By forcing the renaming, you get
somewhat better protection if the profile of a generic subprogram changes
(e.g. by the addition of a defaulted parameter), or at least you get
better error messages.  If a generic instantiation were allowed to complete
a subprogram spec, then if the profile of the generic changed, the generic
instantiation would "morph" into a legal stand-alone instantiation, and you
would get a potentially mysterious message that there was no body found
for the subprogram spec.

> Is for example
> 
>   a[i*4+j-32*k+56] += f(4);
> 
> really more difficult to read than
> 
>   a(i*4+j-32*k+56) := a(i*4-j+32*k+56) + f(4);
> 
> and are these two statements equivalent?

I would agree that "+=" is a nice operation, and I often miss
it when coding in Ada.  However, when you start having things like
"X *= A + B" or "Y /= Z-3" the readability of these shortcuts begins to
drop in my view (due to confusions about precedence, etc.).
In the presence of user-defined operators, it is also unclear whether
things like "+=" should be automatically defined by the compiler in terms
of user-defined assignment and user-defined "+", or require its own
explicit user definition.

From my perspective, the most important thing is to have at least
a *goal* of creating a readable, maintainable, safe language.  Of course
you will miss sometimes, but if you don't even try, you will probably
miss most of the time.

> Markus
> 
> --
> Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
> Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

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