[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tables returning nil if no value
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.
I don't understand. The Table package (interface, module, abstraction,
...) defines and exports a constant of unique type called
UndefinedTableValue. By the contract of the interface, no one stores
that value in the table (why should they?). Everyone knows for sure
that UndefinedTableValue is not a legitimate table value. So there
isn't any possiblity of confusing UndefinedTableValue with any other
As I hinted at in my original message, the UndefinedTableValue solution
is fine but reduces to the TABLE-ENTRY-EXISTS? solution. For consider what
the program that is handed UndefinedTableValue in response to a TABLE-ENTRY
call must do in order to detect that there was no proper value stored in the
table under that key. It could either:
a - Check that the returned value is *not* part of the co-domain of the
function that the table implements, and hence is an "undefined table
value", but writing (BELONGS-TO? V SOME-FUNCTIONAL-DOMAIN) is hard
b - Check that the returned value is the constant UndefinedTableValue
(which is specified by the particular table package the user is using).
However, (EQ? V 'UndefinedTableValue) reduces (i) portability of the
code to other table packages, and (ii) transparency of the table
implementation to the user program.
Thus the user would need to "hide" the "constant of unique type" in an
implementation-independent way, as follows:
c - Define a predicate (UNDEFINED-TABLE-VALUE? V) which returns #t only
to the constant UndefinedTableValue and #f to all other objects (by
checking if V is EQ? to UndefinedTableValue).
But this, of course, is identical to the TABLE-ENTRY-EXISTS? solution (which
has the minor advantage of requiring one less function call). It would be nice
if the table package provided this as part of the interface/module/abstraction
for the reasons outlined in b above.