[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Feb 2 03:13:42 1993 
Subject:Re: dlocals etc. (and shallow binding) 
From:Ray Dunn 
Volume-ID:930204.01 

In refd article, axs@cs.bham.ac.uk (Aaron Sloman) writes:
>[AS]
>> >A really "clean" implementation would have required all local
>> >variables to have their values initialised to some safe default on
>> >procedure entry, e.g. to "undef".
>
>[RD]
>> ...and to take advantage of internal knowledge of the fact that it doesn't
>> raises the hackles of anyone concerned about "future release surprise" or
>> portability!
>
>[AS]
>But note that this has been a dependable feature of every Pop
>implementation for at least 22 years. Suppose it were written into
>the manual, would you still object to its use?

Of course not!  But that's the point.  It never was written into the
manual, so using the "feature" is intrinsically unsafe.  At any time, a
kind system maintainer could have, with perfect validity, decided to
initialize the values of locals on function entry to "undef".

Up to this point, all I'm complaining about (if that's what I'm doing) is
relying on undocumented features.  However:

>>The alternative to these dynamically scoped uses of printlevel and
>> >popmatchvars (and similar things, like interrupt, cucharout,
>> >prmishap, etc.) would have been to require all these values to be
>> >passed explicitly as extra arguments in any procedure that might
>> >call a procedure that used these values, ....

I'm probably being simple minded, but to me, that's precisely what
arguments are for, i.e.  passing external values into a function, and in
fact, that's the _only_ difference between formals and locals.

I see clearly the convenience of what Aaron is suggesting, but like many
programming conveniences it seems to me to lead to opaque code to declare
these things in the same way as locals.  If you're passing the value of
cucharout into a function and protecting the external incarnation, then an
argument's the thing.

>> [POP-2 extra argument example deleted]
>
>Note that this solution works if all printing is done via one
>procedure, which used to be the case in POP2, but is no longer the
>case in Pop-11

Clearly, from your description of the printing mechanism in POP-11, my
"auxilliary function" method becomes cumbersome.

We could of course just manually save and restore the values of the global
variables using other locals for temporary storage, but that (like many
other programming techniques) doesn't work cleanly with jumpouts
("continuations" is a term for this I'm not used to).

>I suspect that Ray's type of solution would be acceptable for
>printing, simply because once you get into any printing procedure
>you stay within printing procedures which call other printing
>procedures explicitly or implicitly (e.g. via class_print), so
>there's no real difficulty in passing on the extra parameters.
>
>More generally, however, there are cases where there's a context,
>e.g. a database of some kind that's extended by a hypothetical
>action, and various different procedures can get called which only
>*indirectly*, via several levels of procedure calling eventually
>invoke the procedure that further extends the context. For that
>situation the extra parameter would have to be supplied to lots of
>procedures that do nothing with it except pass it on. If you have
>lots of such parameters (cucharout, prmishap, database, interrupt,
>etc. etc.) it gets messy. Then Robin's solution of providing a
>single environment that's passed on by every procedure looks like
>the only attractive solution.

Indeed, the single integer we've been discussing for print procedures is
just a subset of this.  It seemed to me when I read Robin's posting, that
he and I were in fact suggesting the same thing, except that I like to hide
the environment passing from the outside world whenever possible by the use
of an _aux_ function.

>What that amounts to is abandoning global variables that can be
>changed locally. It's a consistent way to do things, and maybe has
>some nice properties. I suspect that for a large team of programmers
>developing a suite of interrelated programs that can call one
>another recursively it may be less convenient and less efficient
>than using global variables that are dynamically scoped using
>dlocal. But I don't know.

Perhaps the answer is a new type of declarion in a function specifically
for these things.  Sort of formals that take implicit arguments?
-- 
Ray Dunn at home        |  Beaconsfield, Quebec  |  Phone: (514) 630 3749
ray@philmtl.philips.ca  |  ray@cam.org           |  uunet!sobeco!philmtl!ray