5 ms·

Elm (not mainstream, I concede) wraps list and array access in a Maybe (aka an Option if you're more familiar with ocaml) so there's no throwing or erroring whe

by 1-more 6y ago

Elm (not mainstream, I concede) wraps list and array access in a Maybe (aka an Option if you're more familiar with ocaml) so there's no throwing or erroring when you try to get what's not there. Kinda pleasant.

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 ago
  In 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 ago
    Right, 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 ago
      Returning 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 ago
        I 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)
    - TylerE 6y ago
      It's less clumsy than manual nil checking or checking a secondary error return parameter.

by 1-more 6y ago

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 ago
In 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 ago
  Right, 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 ago
    Returning 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 ago
      I 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)
  - TylerE 6y ago
    It's less clumsy than manual nil checking or checking a secondary error return parameter.