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