[plt-scheme] hash-has-key?

From: Thomas Chust (chust at web.de)
Date: Sat Mar 28 11:43:53 EDT 2009

2009-03-28 Carl Eastlund <carl.eastlund at gmail.com>:
> On Sat, Mar 28, 2009 at 11:11 AM, Thomas Chust <chust at web.de> wrote:
>> 2009-03-28 Carl Eastlund <carl.eastlund at gmail.com>:
>>> [...]
>>> Types have nothing to do with the inconvenience here; typed or
>>> untyped, the result of a successful lookup has to be unwrapped here.
>> [...]
>> in a statically typed language the compiler can automate or aid the
>> unwrapping process more easily.
> [...]
> I thought you might bring that up.  (1) In an untyped language, the
> compiler can still do this kind of thing.  For instance, in Perl,
> strings and numbers are freely converted, and lists are freely spliced
> together.  Automatic coercions do not require static types.  (2) This
> would go back to the original problem.  If you wrapped up the
> 'not-found value in the 'found wrapper, the automatic unwrapping would
> put you back in the situation where you couldn't tell if 'not-found
> meant no value was found, or 'not-found was the value in the table,
> wrapped up in 'found, then automatically unwrapped.
> [...]

Hello Carl,

the problem you describe with automatic coercion in dynamically typed
languages is precisely the reason why this kind of convenience feature
can more easily be implemented "right" in a statically typed language:
If the return type of functions and the declared type of variables is
known at compile time, one can generate automatic unwrapping code
exactly where it is clearly appropriate but nowhere else. For example,
a modern Java compiler inserts automatic casting and unwrapping code
if you write

  int i = someMethodCallReturningGenericObjects();

but will do nothing special if you write

  Object o = someMethodCallReturningGenericObjects();

In the same vein you could generate unwrapping code that throws an
exception if a "not found" value is encountered and strips the wrapper
otherwise for code like

  (let: ([v : ValueType (hash-ref ht some-key)])
    ...)

but not for something like

  (let: ([v : Any (hash-ref ht some-key)])
    ...)

This kind of technique of course creates the usual tradeoff between
convenience when writing the code and transparency when reading it.

cu,
Thomas


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


Posted on the users mailing list.