Aaron Sloman <A.Sloman@cs.bham.ac.uk> wrote:
> David Young wrote
>
> > I got 6/7, wrong on No.1, somewhat surprised at the answer.
>
> I got one wrong because I did not pay attention to the assignment
>
> 5 -> foo;
>
> in the middle of procedure grom.
>
> Anyone who is mystfied by all this should look at two files to start
> with
>
> TEACH VARS_AND_LVARS
>
> Originally written by David!
>
> HELP DLOCAL
>
> Both are accessible as plain text files on the web for people without
> Poplog:
>
> http://www.cs.bham.ac.uk/research/poplog/teach/vars_and_lvars
>
> http://www.cs.bham.ac.uk/research/poplog/doc/pophelp/dlocal
>
> The internal gory details are explained in the Poplog file
> REF VMCODE, accessible as a plain text file here
>
> http://www.cs.bham.ac.uk/research/poplog/doc/popref/vmcode
I got one reply by e-mail from someone who obviously wants to
remain anonymous out of sheer modesty, as he got them all right.
Either that, or he's ashamed of his expertise <g>! (Or most likely
didn't think it was worth posting.)
Yes, I've been reading and re-reading REF VMCODE again. In some
ways, John Gibson's documentation is an even better insight into
how to do things right than reading his actual source code ...
The behaviour is exactly as described in the documentation, but
I wanted to demonstrate it because it is *not* the same as a
Lisp programmer might expect, because dynamically bound variables
are treated as a different "namespace", so that the dlocal
declaration in grom() would bind the foo declared as "vars" at file
level, not the "lvars" foo in grime().
The pop11 behaviour is more correct and more general (kudos to
JG) than the Lisp behaviour (IMNSHO). Moreoever, if anyone
wanted the Lisp behaviour, it's easy to get it: just replace
the
dlocal foo = 4
in grom() by
dlocal %valof("foo")%;
and the uses of foo in both grim and grom by valof("foo").
[(Poplog Common Lisp has the correct lisp-like behaviour.)
Of course, it's not impossible to get the effect of the pop11
behaviour in a Lisp program, albeit with a bit more wear and
tear on the keyboard.]
But the thing that strikes me most is the "completeness" of
JG's design: by going for a powerful general mechanism, there
are no "holes" in what you can do that have to be worked around
using other constructs -- also it "feels" complete. You are not
left with the uneasy feeling that more features might have to
be implemented later.
Of course that does mean that, during implementation, JG would
have had to consider cases that are unlikely to ever occur in a
real program, which sounds like unnecessary effort -- but if
those cases did occur, they'd work as expected! And my experience
has been that, on balance, doing things "right" ends up being
less effort in the long run.
Whenever I'm tempted to take shortcuts in my own programs, I'm
reminded of one occasion when I came across JG sitting, puffing
at a cigarette, and just staring at some code he'd just written,
for a *long* time before he started testing it.
Jonathan
(This seems to have turned into a eulogy. Never mind: I can
post a more negative critique on another occasion <g>.)
|