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.

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.

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.

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.

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.

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.