4 ms·

> Elm requires that you think through all the edge cases. You must consider and specify what will happen in every case. Wouldn't that be the case with _every_

by _xgw 9y ago

> Elm requires that you think through all the edge cases. You must consider and specify what will happen in every case. Wouldn't that be the case with _every_ typed and compiled programming languages (or at least, every typed and compiled programming languages that support pattern matching)?

regularhackerer 9y ago
exhaustive pattern matching
- Multicomp 9y ago
  Exactly. That's why I started using F# wherever I can get away from it at work.
masklinn 9y ago
Not to the same extent, Elm: * sum types and exhaustive pattern matching (incidentally, still not the default in GHC in 2018 because reasons[0]) * has only one escape hatch of "Debug.crash", which it strongly recommends not using and which it seems many Elm devs aren't even aware exists (in my avowedly shallow experience) * and which you use as bottom by hand-rolling pattern matches * at which point you might as well do it correctly To the extent that you can require proper handling of everything, I would say that Elm is much stricter than Haskell or OCaml or Rust. You can be very strict in them, but they don't enforce it to the extent Elm does. At least in my experience. [0] https://ghc.haskell.org/trac/ghc/wiki/PatternMatchCheck https://ghc.haskell.org/trac/ghc/wiki/PatternMatchCheck
- danharaj 9y ago
  GHC will coverage check any case equivalent to one you can write in Elm. You can just write more powerful types where GHC can't tell that your case is exhaustive so it warns about missing branches that won't ever actually be taken. I seem to remember that perfect exhaustive checking for some combination of Haskell extensions is undecidable.
  - dbpatterson 9y ago
    Pattern matching on GADTs will get you there, I believe.
    - wz1000 9y ago
      Its been improved a lot- https://lirias.kuleuven.be/bitstream/123456789/512439/1/icfp2015.pdf https://lirias.kuleuven.be/bitstream/123456789/512439/1/icfp...

by _xgw 9y ago

regularhackerer 9y ago

exhaustive pattern matching

Multicomp 9y ago
Exactly. That's why I started using F# wherever I can get away from it at work.

masklinn 9y ago

Not to the same extent, Elm: * sum types and exhaustive pattern matching (incidentally, still not the default in GHC in 2018 because reasons[0]) * has only one escape hatch of "Debug.crash", which it strongly recommends not using and which it seems many Elm devs aren't even aware exists (in my avowedly shallow experience) * and which you use as bottom by hand-rolling pattern matches * at which point you might as well do it correctly To the extent that you can require proper handling of everything, I would say that Elm is much stricter than Haskell or OCaml or Rust. You can be very strict in them, but they don't enforce it to the extent Elm does. At least in my experience. [0] https://ghc.haskell.org/trac/ghc/wiki/PatternMatchCheck https://ghc.haskell.org/trac/ghc/wiki/PatternMatchCheck

danharaj 9y ago
GHC will coverage check any case equivalent to one you can write in Elm. You can just write more powerful types where GHC can't tell that your case is exhaustive so it warns about missing branches that won't ever actually be taken. I seem to remember that perfect exhaustive checking for some combination of Haskell extensions is undecidable.
- dbpatterson 9y ago
  Pattern matching on GADTs will get you there, I believe.
  - wz1000 9y ago
    Its been improved a lot- https://lirias.kuleuven.be/bitstream/123456789/512439/1/icfp2015.pdf https://lirias.kuleuven.be/bitstream/123456789/512439/1/icfp...