[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tables returning nil if no value

    The correct solution is to return multiple values such as the following:
            (table-entry table key) => found?, value
    where found? is true if there was a <key,value> pair in the table and
    value is undefined if found? is false.

I don't think this solution is "correct", since it violates the semantics
we intuitively expect.  Given a table T, a key K and a value V, we would,
in your scheme, have:

            (set (table-entry T K) V)
            (table-entry T K) ==> something not EQ? to V

I would vote for a predicate TABLE-ENTRY? (like Scott's HT:KEY?) which checks
whether K has an association in T.

I liked your idea of generator functions.  The user may then choose to return
NIL if s/he then wishes.  However, this is obviously orthogonal to the "found?"
problem.  Well, maybe it's not so obvious.  If a table is used as a data
structure common to two modules in a program, there is no a priori way for
the one to know that an "undefined value" (as Ellis suggested) is in fact not
a legitimate value stored in the table by the other.  The only way it could do
this is to test if the "undefined value" belonged to the co-domain of the
function being implemented, which requires an extra test anyway (and one that
is presumably more complex than null?).  Alternatively, the table package
can provide a predicate like valid-undefined-value?, which gets us right
back where we started.

-- Ashwin.