[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jan 19 18:53:42 1994 
Subject:Re: valof evil?! 
From:Steve Knight 
Volume-ID:940121.03 

Daniel asks:
> What is wrong with valof? How else am I supposed to create variable numbers
> of variables?
>
> define dovars(num);
> lvars num;
> 	repeat num times
>     		0->valof((gensym("tike")));
> 	endrepeat;
> enddefine;
> 
> I don't know if this is what it was intended to be used for, but I find it
> useful (maybe this reflects badly on my programming style? :-)

It is best to explain what is wrong with -valof- and then go back and
discuss alternative techniques for living without it.  But let's preface 
this by admitting that -valof- is useful and easy to use.  Sadly there is
a serious problem with it.  (LISPers will be familiar with all that follows 
under the heading of "What's wrong with EVAL?")

In order to make "valof" work properly, it is necessary to carry around 
*all* of the variables that "valof" might access.  Unfortunately, in Pop11,
this is (almost) the same as saying "everything".  As a consequence, when 
it comes to the time to give a Pop11 program to someone you have to give 
them a system with everything in it.  (Well, not quite.  See later.)

To state the obvious -- this means that IF you write a 20 line program that
uses (for example) the matcher THEN you end up giving your customer a 2Mb
executable.  And the customer says "Ummm, what a crummy developer you must
be to write such crummy applications."  And you generally feel put upon and
sad.

But, you might well protest, I'm not delivering to any customers.  I'm a
researcher without a care in the world.  Well -- that's all right -- just as
long as you never write any library code.  As soon as you do, you must shun
the frumious -valof-, on behalf of those of us who do.

Ah, you could easily say, I only use -valof- for a few specific variables.
Therefore, they could be marked as protected against cancellation.  That
way they will survive into the image being delivered to the customer.  Well
that's all right, too.  It is simply more complex than the alternative 
outlined below.  At this point one would be trying to extend a familiar 
technique beyond its natural usefulness.

In any case, there is another problem with -valof-.  -valof- ignores
the small matter of sections.  If you write code which uses -valof-
it cannot be moved safely into a section.  Thus you have frustrated
anyone from using your code in a modular fashion (including, most
seriously, yourself.)


In the specific case mentioned, the usual technique is to use a hash table.
Hash tables in Pop-11 go by the name of "properties" and are described
in user-friendly fashion under HELP PROPERTY and in detail under the
bizarre heading of REF PROPS.

The advantage of a property is that it avoids all the problems.  You
simply use a property to index from one item to another.  All the variables
can be cancelled when delivering to a customer and everything (except
naughty -valof- dependent code) carries on working.  It avoids the problem
of accidental name clashes.  (What makes you think that "tike3" isn't
a favourite variable name of mine (being a pet name for my third son?))
It avoids the inevitable DECLARING VARIABLE messages (which are the 
sign of a broken program).  On some brain-dead ethernet's (like this
one) autoloading take several seconds for each identifier.  And you 
suffer.

In general, you can do all sorts of clever stuff with -valof-.  And there
are corresponding techniques that don't use -valof- but hash tables 
instead.  (This is a slight oversimplification.  Sometimes there are
better alternatives.  But this is a detail.)

I hope this clarifies the problems.  It is bad coding style when there is
a possibility that your code could give someone else problems when delivering
a stripped-down image to a customer.  It is also bad style if you don't
anticipate the knock-on problem caused by making your code section 
dependent.  If you must use valof then make sure it can be moved into
other sections and used when the current-section is something unexpected.

Steve