Re: Problem with instantiating generic procedure

[mgk25@cl.cam.ac.uk (Markus Kuhn)]

Tucker Taft <stt@averstar.com> writes:
|> The rationale behind disallowing a generic instance to be used
|> directly was as follows:
|> 
|>    A generic instantiation does not include any parameter profile
|>    for the subprogram being defined.  Hence, matching it up with
|>    a spec in the presence of overloading could be difficult for the
|>    reader.  On the other hand, a renaming includes a parameter profile.
|>    Hence, matching a spec with a renaming-as-body did not impose any
|>    extra burden on the reader.  Therefore, given the general preference
|>    for readability over writability, renaming-as-body was proposed as
|>    the general solution to problems like this, and instantiation-as-body
|>    was not allowed.
|> 
|> That's the rationale.  I will admit we had a fair amount of discussion
|> before we came to consensus.  It is always tricky to negotiate these
|> readability versus writability issues.  In the long run the emphasis
|> on readability always seems wise, but in the short term, the emphasis
|> sometimes comes across as just being arbitrarily picky.

Thanks for your reply.

In my particular case, I have around 3 generic procedures, from
which I create over 30 instances, which are then made publically visible.
None of thes procedures is overloaded, they do already have different
names. The over 30 "renames" that I have to add now really decrease
the readability of the code. They add unneeded notational complexity
and destroy much of the codes originally intended notational elegance.
Sure, I can live with it, it is just an example where the intension of
restricting the flexibility of the language to support the reader fired
in the wrong direction.

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. Really readable
programs can only be achieved with the active cooperation of the writer.
I think it is not wrong to leave many aspects of what is more readable or
not at the discretion of the writer. It is difficult to forsee all possible
situations at language design time. Indirections and the introduction of
new names can also make code significantly less readable. Our brains have
fixed neurophyisiological limits as to how many objects we can
simultaneously handle in our short-term memory (in the range of 6-8 for
healthy adults), and a blowup in notation will consume some of this very
limited capacity. Sometimes a compact (even if semantically more complex)
notation can help readers to process and perceive the overall situation
hierarchically, while a more lengthy but semantically simpler form does
not support this. Ada unfortunatelly choses sometimes a bit too much
of the latter alternative and I think we have seen an example here.

One of the more important things I learned the hard way over the time was,
that some things are difficult to reason about in a theoretical manner.
They have to be tried and measured instead to get meaningful results.
The performance and efficiency of machine code on modern branch-predicting
superscalar CPUs is one good example. The readability of some
language syntax and semantic for experienced readers is another one.
Both can very easily be misestimated if they are just discussed at an
abstract level without good experimental verification.

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?

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?

Markus

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