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: Tucker Taft Subject: Re: Problem with instantiating generic procedure Date: 1999/07/23 Message-ID: <3798EAD2.F6C8694B@averstar.com>#1/1 X-Deja-AN: 504565110 Content-Transfer-Encoding: 7bit Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.burl.averstar.com References: <7mqfcq$9og$1@pegasus.csx.cam.ac.uk> <37934B7D.926D3B6D@averstar.com> <7n09mg$anc$1@pegasus.csx.cam.ac.uk> Content-Type: text/plain; charset=us-ascii Organization: AverStar (formerly Intermetrics) Burlington, MA USA Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-07-23T00:00:00+00:00 List-Id: 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: -- -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