Re: Function Calls by Address

[Robert Dewar <robert_dewar@my-deja.com>]

In article <37D2F41D.AE1C85F5@magic.fr>,
  Francois Godme <fgodme@magic.fr> 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.