[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jan 25 02:35:18 1994 
Subject:Re: valof evil?! 
From:"A.Sloman" 
Volume-ID:940125.01 

Steve writes
> Daniel asks:
> > What is wrong with valof? How else am I supposed to create variable numbers
> > of variables?
> ....
> 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.

Not necessarily. I can easily give them a few files that they load in
their poplog system (I'll deal with name clashes below).

Of course, if you want to deliver tiny programs to non poplog users, as
a C programmer would, then the situation is different. But for very many
people that's not a consideration. E.g. a bunch of Poplog users who
mainly use VED for reading and writing mail, reading and posting news,
sharing a documentation database, etc. can also share a collection of
utilities using some global variables, with autoloading and use of
valof. It's no big deal, as long as you know what you are doing.

The strictures that might be relevant to producing a software "package"
to be sold in binary form, or combined by all sorts of unknown people
with all sorts of software, are irrelevant. In particular, with careful
choice of identifier names you don't need to bother with sections if you
are dealing with a suitably restricted group of users.

> 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.

Nowadays, all sorts of trivial things are 2Mb or more. Space is less and
less of a problem. The only problem is that big things can start up
slowly, and that is reduced by decent demand paged virtual memory
systems, faster disks, etc. Wherever possible we should let hardware
developments take the burden of efficiency: over the last ten years or
so my programs have speeded up by a factor of about 100 to 150 without
my doing anything about it; and in the cases where memory shortages used
to lead to excessive paging the speed up is much higher. I expect this
to continue.

>
> 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.

NOPE. I've used it often and friends and colleagues have used my code
without a care in the world. Similarly people whose the autoloadable
goodies in the Poplog libraries are all using valof, implicitly.

>
> 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.

I generally deliver user-loadable or autoloadable libraries, not images,
except that occasionally a group of people may decide to share a saved
image.

> ..Well
> that's all right, too.  It is simply more complex than the alternative
> outlined below.

No. It's very simple. Just choose your identifiers carefully. This is a
problem that you can't get round just by using sections: any package of
the sort you are talking about, must be accessible to the other code. So
there has to be at least in part a common name space, and if you use
sections or packages all you are doing is making the name space (for
exported identifiers) richer by having names composed of section name
plus variable name. It's still possible for someone else to choose the
same section name and variable name as you, but for a totally different
purpose: and then your programs can't live together unless you go to a
lot of trouble to put them in different sections and then export
synonyms that don't clash.

Choosing section names carefully is no easier than choosing identifier
names carefully. If you use common names like "x" as one of your
arguments to valof you are asking for trouble. If you use
"sfk_package_x" then you are pretty safe.

Of course, if you don't need to be able to map values on to words
typed in unexpectedly at run time then instead of generating words
and using valof you can generate other structures, e.g. references,
and use their field selectors. I.e. build the association directoy
into the items associated, for instance with consref and cont.

> 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.)

Well there are degrees of modularity, and for certain kinds of
communities and working practices it's just not a problem. I would
agree with you as regards products to be delivered to unknown people in
unknown environments, and to be combined with unknown sorts of alien
software.

It may be worth mentioning that in some of the cases where valof is used
you can get a section-proof version by using idval applied to the
*identifier* instead of valof applied to the *word*. It's not easy to
do, however.

LIB FMATCHES is a version of the Pop-11 pattern matcher that uses idval,
and therefore copes with sections and lvars.

> 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.

I agree that properties are very useful. However, it's worth pointing
out that besides properties there are many ways of associating items,
e.g. using association lists, or indexing from numbers into a vector
of items, etc. You can even set up an association using inline code,
if you know all the cases in advance:
	getinput() -> word;
	if word = ... then ....
	elseif word == ... then ....
	etc.
Properties are useful when the association table (or multi-branch
conditional) is going to be very large, and therefore slow to traverse
in a linear fashion. A 2-D array is useful if you want to map pairs
of numbers to items, and so on.

Incidentally, newmapping is quite useful for mapping complex structures
to other things with having to deal explicitly with the full horrors of
newanyproperty or your own hashing algorithm. See HELP NEWMAPPING

It may be worth mentioning that even when you use a quoted word you are
implicitly using a hash table that maps the sequence of characters onto
a word record. That's how the Pop-11 dictionary is accessed efficiently.

> 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?))

Yes, the shorter an identifier is, and the closer it is to an English
word, the more likely you are to clash with another use of it, either by
another user, or by yourself in six months time. So anyone who is going
to use valof, or any global variables that matter, must use fairly long,
carefully chosen variable names.

> It avoids the inevitable DECLARING VARIABLE messages (which are the
> sign of a broken program).

Come now: a program that is creating variables can declare them to avoid
those messages, and to avoid unwanted autolading. See ident_declare
in REF IDENT. (Not sysdeclare, which first tries autoloading.) You don't
have to eschew valof for this purpose.

> ....On some brain-dead ethernet's (like this
> one) autoloading take several seconds for each identifier.  And you
> suffer.

You can also slow down other users by excessive disk searches.

> 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.

Or choose names that you think are no more likely to clash than a
combination of section name and identifier name.

Oh dear, I've gone on too long.
Aaron