[plt-scheme] hash-has-key?

2009-03-30 Sam TH <samth at ccs.neu.edu>:
> On Mon, Mar 30, 2009 at 9:51 AM, Thomas Chust <chust at web.de> wrote:
>> 2009-03-30 Sam TH <samth at ccs.neu.edu>:
>>> [...]
>>> What if the hash table had type Hash[String, Any]?
>>
>> Then the return value of hash-ref would have type Option[Any], any
>> value found in the hash table would be returned by hash-ref wrapped as
>> a Some[Any] -- I don't see any problem there.
>
> Consider this program fragment (in some pseudo-syntax):
>
> let h : Hash[String,Any] = (make-hash ...)
> let x : Any = (hash-ref h "foo")
>
> Does this code do auto-unwrapping?

I would say that the compiler should be conservative and not do
auto-unwrapping. But this is indeed a somewhat ambiguous case.

>>> [...]
>>> What if our language contains type inference?  What is the inferred
>>> type of (hash-ref h k)?
>>
>> For any h of type Hash[K, V], hash-ref either extracts a value of type
>> V from h and returns it wrapped up as a Some[V] or it returns the
>> unique value of type None. The most specific common supertype of
>> Some[V] and None is Option[V] and this should be the type inferred for
>> hash-ref -- I don't see any problem here, either.
>
> Let's say that I write this modification of the above code:
>
> let h : Hash[String,Number] = (make-hash ...)
> let x  = (hash-ref h "foo")
>
> what type is inferred for `x'?
> [...]

Here I would say it's clear that the inferred type of x should be
Option[Number], unless the type inferencer wants to look at every use
of x to implement a more clever behaviour. Automatic type conversions
should not be considered when inferring the type for something that
has no programmer specified type constraints on it.

Anyway, I never claimed that this approach would solve all possible
problems nor that I particularly liked it, only that it makes it
possible to return a unique "not found" value from certain lookup
operations on collections :-)

cu,
Thomas


-- 
When C++ is your hammer, every problem looks like your thumb.