Map policy
Posted: March 13th, 2011 | Author: Mars | Filed under: Design, Progress | 1 Comment »I’ve been making some progress on the map datatype, one of a handful of built-in data structures. I decided to take the cheater’s way out and write it in C, inside the runtime library, instead of following my original plan and building it up from primitives (tuples) in Radian itself. I can always come back and rewrite it later; for now I am more interested in getting the language bootstrapped.
I’m considering a policy decision: what happens when you try to insert a value to a key which is already present? Does the map raise an exception, since you’re trying to do something whose meaning is somewhat ambiguous, or does it simply replace the existing value with the new one? The same question applies to the other map operations: what should happen if you try to remove a key which is not present? Does the map remain unchanged or raise an exception? Is the operation “make a map which lacks this key”, or “remove this key from the map”?
I am leaning toward raising exceptions in all of these ambiguous cases, because it seems more correct than making a policy decision which might be wrong sometimes. I am concerned that this will be annoying, though, and that the first thing I will end up doing is building a wrapper around the stock map that has the “just do it” behaviors.
It seems to me that the “make a map which lacks this key” behavior is more in line with functional programming. In evaluating the expression, you care about the resulting value (a map without that key), not the action itself (mutating the map by removing that key).
To put it another way: you don’t care if the key existed before, as long as it’s gone after.
On the other hand, I think most languages throw if you try to remove a nonexistent key. I always end up having to guard removes with if’s or try/catch statements, which I find annoying.