Make hashmap[val] return an error when val is unbound

[ChrisJefferson]

At the moment, hashmap[val] return fail when val is not in hashmap. This is inconsistent with lists, where l[2] returns an error if 2 is not bound in a list l.

My suggested fix:

1. Make hashmap[val] return an Error if val is unbound.

2. Add a new function Lookup(map, key [,default]), which returns map[key] if that is defined, and default otherwise. If default is ommitted, treat it as fail, which gives the behaviour of the current hashmap[val].

[stevelinton]

When default is mutable (or maybe even copyable) it matters whether Lookup actually binds that value to key as well as just returning it, or not.

[ChrisJefferson]

Hmm.. at first I thought I wanted lookup to bind, but now I think it shouldn't.

As a comparison, it doesn't bind in either python or ruby.

[stevelinton]

You'd need a way to tell the difference between default returned as default and default returned because it was actually stored.

Also having some function that binds, or a quick way to bind to the last place you looked at (not very thread-friendly) actually saves work in many common use cases.

[stevelinton]

Another thought -- this is really a question for all "map" data structures. It would be nice to have a uniform API that covered this and the accumulation functions in Max's current implementation. There are a bunch of graph-theoretic and orbit-like algorithms that could be expressed effectively in that framework -- orbit & stabilizer, shortest path and cycle-finding algorithms and so on. Then any data structure that provided this API could be used efficiently and interchangeably without changing the application code.