Re: Tables returning nil if no value

[Ashwin Ram <ram@YALE.ARPA>]

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


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

    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.

-- Ashwin.




-------