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,8ceb83dbf250e264 X-Google-Attributes: gid103376,public From: mgk25@cl.cam.ac.uk (Markus Kuhn) Subject: Re: Problem with instantiating generic procedure Date: 1999/07/19 Message-ID: <7n09mg$anc$1@pegasus.csx.cam.ac.uk>#1/1 X-Deja-AN: 502895179 References: <7mqfcq$9og$1@pegasus.csx.cam.ac.uk> <37934B7D.926D3B6D@averstar.com> Organization: U of Cambridge Computer Lab, UK Newsgroups: comp.lang.ada Date: 1999-07-19T00:00:00+00:00 List-Id: Tucker Taft 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: