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, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,88e7ef9008757431 X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: Function Calls by Address Date: 1999/09/06 Message-ID: <7qvbhc$t47$1@nnrp1.deja.com>#1/1 X-Deja-AN: 521514600 References: <37CADE68.6AF06F5D@escmail.orl.lmco.com> <37CEEFFA.7D73F78D@magic.fr> <7qooh7$hbh$1@nnrp1.deja.com> <37CFFEA6.921CBE59@magic.fr> <7qsrtj$9lp$1@nnrp1.deja.com> <37D2F41D.AE1C85F5@magic.fr> X-Http-Proxy: 1.0 x34.deja.com:80 (Squid/1.1.22) for client 129.37.100.83 Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Mon Sep 06 03:13:55 1999 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-09-06T00:00:00+00:00 List-Id: In article <37D2F41D.AE1C85F5@magic.fr>, Francois Godme wrote: > There are two kinds of nested procedures: the ones which do > not make > uplevel references and the others which do. You gain possible reuses by > unnesting the former. But if you are using procedures as top down refinements, you do NOT want reuse .. you seem to think of procedures only in the bottom up library context. That's just one use. Decomposition by refinement is another important use, and here locality is important, reuse is not. > You gain clarity by rewritting the latter to avoid > the uplevel references. All the hidden parameters as well as their > passing modes are then shown. Once again, you are thinking in terms of procedures only in the bottom up context. When you write a chunk of code say, something like: if bla bla then dum-de-dum-dum ... You do not sit around thinking, oh-my-gosh, the dum-de-dum-dum code has naked references to surrounding context. I should make it into a procedure which should have parameters to show all the hidden parameters etc etc. However, if you are following the notions of top down refinement, you might well say to yourself hmmm .. dum-de-dum-dum is a bit long and not really at the same level of abstraction as the surrounding tests etc, the code will be clearer if I abstract this into a nested procedure which can be separated out, and give this procedure a nice name There is no more reason to worry about passing the environment to this refinement than there is to worry about passing it to the naked dum-de-dum-dum code in the first place. There is a whole dimension that you are missing here. I recommend reading the rationale behind the Algol-68 modules extension which goes into the need to have separate abstractions for top down and bottom up programming in detail. It is true that many programmers tend to think one way or the other. For a while in the mid 80's it was fashionable to think ONLY in terms of top down refinement. More recently I see a lot of programmers who seem to think only bottom up. The proper approach is to known and understand both approaches, and to use the appropriate one. It is definitely true that the programming language has an effect here. COBOL, with its very light (much lighter than C or Ada) syntax for local refinements, tends to encourage the use of the top down approach. Languages like C which do not allow nested procedures tend to discourage this style. Ada is somewhere between, the syntax for local procedures is a bit heavy, so people do not use them as freely as they do in COBOL (example below), but on a slightly larger scale, they are definitly put to good use, and the idea that eliminating all up level references increases clarity of code is very much mistaken. The promised COBOL example ... Process-Balance. if Balance is negative perform Send-Bill else perform Record-Credit end if. Send-Bill. ... Record-Credit. ... with a syntax this light for internal refinements, they tend to be extensively used, one of the features I like best about COBOL, and indeed COBOL programmers dislike nested if statements (they are fully implemented Ada style in COBOL), on the grounds that they are confusing :-) :-) Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.