[R6RS] Table proposal

Marc Feeley feeley
Mon Apr 25 17:25:56 EDT 2005


On Apr 25, 2005, at 4:39 PM, Matthew Flatt wrote:

> At Mon, 25 Apr 2005 15:27:52 -0400, Marc Feeley wrote:
>> As you may have noticed, a hash table SRFI (SRFI-69) has just been
>> announced.  In many ways it is similar to my proposal, in other
>> ways it is different.  I'd like to comment on SRFI-69, but only
>> after there has been some discussion of the table proposal by the
>> committee.  So please take a minute to read my table proposal and
>> comment on it.  I'd like to know if you are generally favorable
>> or not.
>
> Both are fine drafts to me. I have a slight bias in favor of the SRFI
> version, but it's nothing to do with the content --- only that we
> should take advantage of the SRFI process whenever it's reasonable.

What about the additional features supported by the table proposal,
i.e. weak-keys and weak-values, the ability to supply table settings
when the table is created (key comparison procedure, key hashing
procedure, table load limits), the ability to create eq? tables (which
I consider to be the most important type of table anyway), and the
restrictions on table-for-each and table-search.

> I have one suggestion, which is the same for both proposals: instead of
> a default value for for `table-ref', accept a thunk that is tail-called
> when the key is not found, and make the default thunk report an error.
>
> In quick scripts where `table-ref' is used with the assumption that it
> will find a value, getting a "no value for X in table" error is usually
> more helpful than an "expected Y but got #f" error.
>
> In not-so-quick programs, the usual benefits of failure thunks apply.

But the specification is that this default value is optional, and
if you don't supply it and the key is not bound an exception
is raised.  I don't like failure thunks because they duplicate
the functionality of the exception system and they are less
efficient for some things because a closure needs to be created
(even if the key is seldom unbound), i.e. instead of

      (let ((unique (list 0)))
        (eq? (table-ref table key unique) unique))

you would have to write the following which always allocates a
closure:

      (let ((unique (list 0)))
        (eq? (table-ref table key (lambda () unique)) unique))

Most hash table interfaces I've seen have a default value like
the one in my table proposal.  In fact, I think MzScheme is the
only one with a failure thunk.

Marc



More information about the R6RS mailing list