4 ms·
It is useful to differentiate this, though. Consider a datatype of map with values of type T. The function to return value for a key returns None when the key i
by js8 3y ago
It is useful to differentiate this, though. Consider a datatype of map with values of type T. The function to return value for a key returns None when the key is not in the map, but what if the key is in the map, but the actual value is None? IIRC Lisp has a workaround but it requires special code to handle maps that can have None as values.
As the other posters have said, it (automatically flattening the Maybe monad) is non-composable and should be considered a bad language design, like it was a bad idea to automatically flatten lists in Perl.
- bombolo 3y agoThat's why in python that raises a KeyError, or if you use explicitly .get() you can specify anything as your default value.
- codebje 3y agoIt's probably subjective, but I don't see the need to wrap your code in a try/except block as an improvement over an optional sum type, and I really don't see the use of a magic value to indicate no value as an improvement over anything.
- bombolo 3y agoIf it's not a try it's an if... you still need to handle the case where the key wasn't present and figure something out.
- lmm 3y agoWhich is why you end up with the painful sentinel = object() value = dictionary.get(key, sentinel) if(value == sentinel) ... Which, sure, it works, but it's working around a problem that didn't need to exist in the first place. Why not just have Option work the way you expect, and be able to contain None the same way as it can contain any other value?
- kaba0 3y agoArguably, composing/depending on the composability of optional values is also a code smell. A Some(Some(None)) may be occasionally okay, but it is almost always better represented by an explicit type. Also, clojure can better express these in-between states, as demonstrated by the very good talk (I swear Hickey always sells me on Clojure.. I really should write something more serious in it)