Email list hosting service & mailing list manager

Prototypes Michael Burschik (10 Apr 2003 06:21 UTC)
Re: Prototypes Taylor Campbell (18 Apr 2003 03:24 UTC)
AW: Prototypes Michael Burschik (23 Apr 2003 06:08 UTC)
Re: AW: Prototypes bear (23 Apr 2003 16:46 UTC)
Re: AW: Prototypes Tony Garnock-Jones (24 Apr 2003 09:27 UTC)

Re: AW: Prototypes bear 23 Apr 2003 16:46 UTC


On Wed, 23 Apr 2003, Michael Burschik wrote:

>> > It might also be mentioned that the return
>> > value is ambiguous with regard to #f, which might be a
>> > vector element that
>> > satisfied the predicate, or signal that the end of the vector was
>> > reached without satisfying the predicate.
>>
>> Can you think of a better thing to do in this case?
>
>I can think of no elegant solution. Of course, you could always return
>both the index and the element found.

In my hash table library there is an optional third argument
to the lookup function.  It's the value to return in case
you don't find something.

So you call

  (hash-lookup htable key #f)

and if it's not in the table, it returns #f.

But if you call

  (hash-lookup htable key 'NOTFOUND)

it returns NOTFOUND.

I figured it was the right thing to do considering that no
matter what value you pick to return when something isn't
found, it could also be interpreted as the value stored under
that key.  That makes it a programmer choice instead of a
library choice; the programmer, knowing what's stored in the
table, will know what can be used safely as a meaningful
thing to return if something's not there.

I suppose you could make it optional, with a default value
of #f if you want.

			Bear