3 ms·

How do fatal errors (like asserts) work in Elm? Are assertions considered to have side effects? What if the removed function call would have produced an import

How do fatal errors (like asserts) work in Elm? Are assertions considered to have side effects? What if the removed function call would have produced an important error?

Blikkentrekker 6y ago
If it be like in any other pure language, as far as the type system is concerned fatal errors do return a value. It's no different from a function entering into an infinite loop and never returning. It has a return type; it simply doesn't ever return. Some type systems go further and have the type system differentiate between total and partial functions, where total functions are guarantee to always return a value of their type eventually.
- millstone 6y ago
  The post says "there is no observable difference between calling a function and not using the result, and not calling it at all." But you just described an important difference! In Haskell one must use the assertion's result to trip the assertion, which can be awkward. But Elm is strict; I wonder how assertions are treated in this sort of DCE.
  - Blikkentrekker 6y ago
    Methnks you approach the control flow differently, as in for instance in pseudocode: assert(list.len() > 0); //code that assumes that the list not be empty Whereas in a functional language, what would happen is: if list.len() > 0 then // code assumes that the list not be empty else assertion_fail("list is not empty") Functional languages lack sequencing syntax that execute two expressions, ignoring the result of the first, altogether, and every function definition is one single expression. One does not as such first makes an assertion as the first element of a sequence, and then proceeds under the assumption that the assertion did not fail, but rather calls the `assertion_fail` function on some code paths, which then never returns if ever it be reached. The type system will call the function all the same, as as far as the type system and language runtime is concerned, it is an ordinary function that will return a value of the expected type, but under the hood it aborts the entire program, and prints proper diagnostics.
jfmengels1 6y ago
Elm doesn't have asserts. Instead, what you'd do is to have the function return a potential error (what in Elm we'd call a Result). so instead of function a(b) { assert(b > 0); return b + 1; } you'd do a b = if b > 0 then Ok (b + 1) else Err "b was not > 0" To then use the result of the function call, you'll need to unwrap the result, by handling the case where the function returned Ok, but also the case where you return Err case a -2 of Ok b -> -- display the value b Err errorMessage -> -- display the error message THis is the kind of technique Elm uses to ensure that you'll have no runtime errors in your code: by forcing you to handle the error cases. The nice thing is that the types can indicate whether something can fail or can't.
- account42 6y ago
  Asserts are not for runtime errors, but for verification of assumptions in debug builds. Essentially, they are mini-test run on real data during normal use (of a debug build). Making it so you can't have asserts will just mean that you won't have those kind of tests.
  - jfmengels1 6y ago
    Ah alright. That's an interesting technique! You can't do that in Elm, you'd have to rely on the technique I mentioned above and regular tests.

How do fatal errors (like asserts) work in Elm? Are assertions considered to have side effects? What if the removed function call would have produced an important error?

Blikkentrekker 6y ago

If it be like in any other pure language, as far as the type system is concerned fatal errors do return a value. It's no different from a function entering into an infinite loop and never returning. It has a return type; it simply doesn't ever return. Some type systems go further and have the type system differentiate between total and partial functions, where total functions are guarantee to always return a value of their type eventually.

millstone 6y ago
The post says "there is no observable difference between calling a function and not using the result, and not calling it at all." But you just described an important difference! In Haskell one must use the assertion's result to trip the assertion, which can be awkward. But Elm is strict; I wonder how assertions are treated in this sort of DCE.
- Blikkentrekker 6y ago
  Methnks you approach the control flow differently, as in for instance in pseudocode: assert(list.len() > 0); //code that assumes that the list not be empty Whereas in a functional language, what would happen is: if list.len() > 0 then // code assumes that the list not be empty else assertion_fail("list is not empty") Functional languages lack sequencing syntax that execute two expressions, ignoring the result of the first, altogether, and every function definition is one single expression. One does not as such first makes an assertion as the first element of a sequence, and then proceeds under the assumption that the assertion did not fail, but rather calls the `assertion_fail` function on some code paths, which then never returns if ever it be reached. The type system will call the function all the same, as as far as the type system and language runtime is concerned, it is an ordinary function that will return a value of the expected type, but under the hood it aborts the entire program, and prints proper diagnostics.

jfmengels1 6y ago

Elm doesn't have asserts. Instead, what you'd do is to have the function return a potential error (what in Elm we'd call a Result). so instead of function a(b) { assert(b > 0); return b + 1; } you'd do a b = if b > 0 then Ok (b + 1) else Err "b was not > 0" To then use the result of the function call, you'll need to unwrap the result, by handling the case where the function returned Ok, but also the case where you return Err case a -2 of Ok b -> -- display the value b Err errorMessage -> -- display the error message THis is the kind of technique Elm uses to ensure that you'll have no runtime errors in your code: by forcing you to handle the error cases. The nice thing is that the types can indicate whether something can fail or can't.

account42 6y ago
Asserts are not for runtime errors, but for verification of assumptions in debug builds. Essentially, they are mini-test run on real data during normal use (of a debug build). Making it so you can't have asserts will just mean that you won't have those kind of tests.
- jfmengels1 6y ago
  Ah alright. That's an interesting technique! You can't do that in Elm, you'd have to rely on the technique I mentioned above and regular tests.