6 ms·
intersting. how's that work out in practice? seems like it could be clumsy. e.g. what does binary search look like in elm? in general i always thought out-of-
by dilap 6y ago
intersting. how's that work out in practice? seems like it could be clumsy.
e.g. what does binary search look like in elm?
in general i always thought out-of-bounds controlled-crashing seemed the program was a reasonable thing to do, since it's arguably a bug in the program, not an error in input.
or what about integer oveflow? or divide by zero, it would seem very impracticle indeed to wrap all those operations in maybe...
- TylerE 6y agoIn languages with pattern matching (which I assume Elm has, although I've never used it personally, it's very natural. A portion of a binary tree walk in pseudo-code might look something like match (s.left){ with Some x -> recurse(s.left) Nothing -> pass } Basically the difference is that it forces you to deal both branches (In a typical pattern match, you either need to explicitly handle all subtypes, or have some sort of catch-all/default case) and it makes sure you can't call the "do something" branch when you actually have nothing.
- dilap 6y agoRight, but that's for a context where None is a natural value. Have array access return maybe would be much less convenient. What would binary search look like? How about integer division? How about addition, which might overflow? Modeling all possible failures as maybe seems like it would be clumsy...
- mpalmer 6y agoReturning a Maybe for an array access captures the context of possible failure inherent in that operation. Not handling it doesn't make it go away. Luckily, languages with parameterized types (Maybe being one) let you write generic code to handle Maybes. You might be envisioning overly nested conditionals, but languages more or less avoid this
- dilap 6y agoI get that, but I feel like the questions I'm curious about have still not been answered... 1. Array out of bounds is different than other types of errors, like e.g. file does not exist: Because the size of the array is entirely controlled by the program, and a non-buggy program can completely avoid array out of bounds, it knows its access to the array will not return None: Array access returning None is not an inherent condition that must be handled by any program. So my question is, what does this look like then in conditions when you know you won't access out of bounds? Specifically, that makes me wonder what a binary search implementation in Elm would look like. Binary search knows it will not access outside the bounds of the array. So how do you handle get returning Maybe? Do you just assert the result is not null? OK, I got curious and searched, and here's one random implementation: https://github.com/terezka/elm-algorithms/blob/master/BinarySearch.elm https://github.com/terezka/elm-algorithms/blob/master/Binary... The answer is it checks for Nothing (which should never happen!) and just returns -1 if it does happen. This does not seem good to me! If Array.get is returning Nothing, this indicates a bug in the binary search implementation. Instead of getting a panic or crash or other indication that a bug has ocurred, the design of get has encouraged the author to silently swallow this condition and return -1. 2. Second question: There are many of other kinds of problems that can happen besides array out of bounds access; it seems unclear to me how you could handle that with Maybe: What if you divide by 0? What if you overflow the range of a type? What if you run write a recursive function that exhausts memory? In summary, Maybe to handle places where the program is genuinely uncertain about something is great, but I'm unconvinced of its value in modeling situations that should never occur in a non-buggy program. I've been playing with the Zig language recently, and I feel like it gets this exactly right. - Optional types for cases where a value might or might not be there - Sum-type with a set of errors and the value for cases where program input may result in an error - Crash with a stacktrace for cases where a bug in the program is detected (e.g., array out of bounds access)
- 1-more 6y ago-1 seems ok here. The algo is returning the index at which the array contains the search value; returning -1 is a pretty normal way of indicating that there is no such index. She could of course change the search function to return a Maybe Int, then return Nothing in the case where the array does not contain it. Either way makes sense to me. The -1 value is actually warming on me more and more because if the returned index is later used to access the array, it will definitely return Nothing. But using Maybe.andThen to monadically deal with a Maybe wrapped return value that would also be cool. Float division by zero works the way IEEE floats work: it becomes +/- Infinity. For Integers it actually becomes zero. This makes sense because to me you probably should have handled the case where the denominator was 0 before you got to the point of doing division. Like are you taking the mean of an empty list? What's going on?
- TylerE 6y agoIt's less clumsy than manual nil checking or checking a secondary error return parameter.