Tables returning nil if no value

[Scott W. Layson <x.Gyro@OZ.AI.MIT.EDU>]

    Date: Wed, 26 Mar 86 14:09:43 EST
    From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>

    The correct way to deal with lookup failure is NOT to return a second
    found? value, but instead to either build failure into the language (as
    in Prolog, Snobol, or Icon, or zetalisp's condition system), or to pass
    multiple continuations (like PDP-10 assembly language programmers do):

Perhaps the correct way to carry on this discussion is not to introduce
proposals as "the correct way..."?

      (table-entry table key
		   (lambda (val) ... success ...)
		   (lambda () ... failure ...))

    Given that neither of these alternatives seems particularly realistic
    (the first because it's too drastic and the second because it's just as
    cumbersome as dealing with multiple values), I think the way it is is
    better.

Is dealing with multiple values all that cumbersome?  I don't have my T
manual with me, so can't check, but I wrote a macro NLET for ZetaLisp
that allows, among others, the following syntax:

  (nlet ((found? value (table-entry table key)))
    ... body ...)

i.e., in each clause, all forms but the last are symbols to be bound to
the values returned by the last form.  It expands, of course, to the
much less pretty MULTIPLE-VALUE-BIND.

In this particular case, however, I must say I like the semantics of
Jon's multiple-continuation approach (because it avoids the bugaboo of
having some variable, e.g. VALUE in the above example, bound to an
undefined value).  My experience with such things is that if the
semantics is right, it's worth the effort to fiddle with the syntax
until it's no longer cumbersome.  In this case, it's easy enough to have
the default continuation be used in case of success, so only one extra
need be specified:

  (table-entry-efc table key (lambda () ... failure ...))

where "efc" stands for "explicit failure continuation".  Then it's easy
enough to define table-entry in terms of table-entry-efc.  (One can
imagine -EFC versions of most if not all system primitives.  Somehow,
allowing the user explicit access to these strikes me as far more
elegant than ZetaLispoid CONDITION-BIND and other such.  It would also
bring the "error handler" out into the open, in the sense that somewhere
there would be code that defined + in terms of +-EFC, etc., which the
user could read and create her own versions of.)

There's a whole 'nother approach to problems like this that I may as
well mention, for completeness.  TABLE-ENTRY could return an object
which supported FOUND? and VALUE operations.  I think it would be very
worthwhile to teach the compiler to implement this essentially
identically to the multiple-value version (i.e. without ever consing the
object in the heap (assuming the situation is such that that's not
strictly necessary)).

-- Scott