the "no runtime exceptions" claim

[Janis Voigtländer]

Re:

I think "No runtime exceptions" is true except for cases where there are compiler bugs, namely "no errors on incomplete pattern matches" and "no errors on bad self-recursive values". Given these bugs, maybe I am too eager to get to the "greater truth" which is that there really are practically no runtime errors.

Has anybody opened GitHub issues for these two compiler bugs (if that's what they are being seen as)?

I'd like to add a third one:

https://groups.google.com/d/msg/elm-discuss/tKZQ1DvBVhw/oRqfersDKgEJ

Actually, one could argue that this one is indeed a language issue, not a compiler issue. There is an expression that the language's type system claims is okay, but at runtime the program fails irrecoverably. And I don't see how to fix this by fixing the compiler. It needs a change to the language's type system. Right?

[Richard Feldman]

+1 for resolving this in a way other than throwing a runtime exception.

Another two options that come to mind:

1. Define the behavior as comparing function references (in other words, identical semantics to JavaScript's === when it comes to functions)
2. Define the behavior as always returning false for any given two functions.

[Janis Voigtländer]

Yes, these options would move this into the realm of something doable in the compiler without changing the language’s type system. They are mathematically not nice (== ceases to be a congruence relation), but pragmatically acceptable. In any case, something should be done about this before making any public claims that Elm admits no runtime errors.

​

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Janis Voigtländer]

Richard’s 1. option is implemented by this simple fix.

​

[Joey Eremondi]

Some comments on the claim in general:

I think it's important to qualify the claim that there are no errors, and not claim thing that aren't yet true. Here's what I'm worried will happen:

• New user tries Elm
• Because user is new, user has an incomplete pattern match, or a one-armed if statement
• Elm gives a runtime error
• User sees that Elm does throw runtime errors, gives up because product didn't match description
  

I think it's reasonable to have no runtime errors within a few months, but I think we have to be very careful about making the claim before it's true, since those who are least experienced are the most likely to accidentally cause runtime errors.

[Hassan Hayat]

There are other runtime errors aside from incomplete pattern matching. This is just a collection of the ones I've found.

Mutually recursive records: https://github.com/elm-lang/elm-compiler/issues/912

Using toString in records : https://github.com/elm-lang/elm-compiler/issues/897

Weird tuple error : https://github.com/elm-lang/core/issues/201

Broken eq on some unicode strings: https://github.com/elm-lang/core/issues/177
Array repeat given negative value : https://github.com/elm-lang/core/issues/175

Some of these errors are obscure but others aren't like the mutually recursive records one. It is not inconceivable for a beginner to try this (or even a non-beginner to do this by accident), especially when you also say stuff like "in pure functional languages, order doesn't matter". 

I agree that the claim is too strong. I'd tame the claim a little and focus more on things like the time traveling debugger, or simpler architecture, and so on...

[Hassan Hayat]

In this spirit I just opened up an issue on elm-compiler so you can throw whatever runtime error you have found there. I think it's important to organize them in one spot so we know what's there. I have only included mine, so if you have others please include them with their respective issue link. 

Link to issue: https://github.com/elm-lang/elm-compiler/issues/913

[Brian Slesinsky]

I don't think it's a good goal to aim for no runtime errors, even in principle. This will encourage people define away awkward errors that are difficult to detect at compile time, but really should be reported. Replacing a runtime error with no error message at all and an unintended (but specified) behavior is making things worse.

As an example of how this can go wrong, MySQL cannot report errors in some parts of the query engine, so they define datetimes strangely to include impossible dates [1]. Also, JavaScript has unintuitive data type conversions because back in the beginning, they were unwilling to throw an exception when the data couldn't sanely be converted.

[1] https://dev.mysql.com/doc/refman/5.7/en/date-and-time-types.html

[Richard Feldman]

Invariants are really powerful. Not having to worry about runtime exceptions from your Elm code frees your brain from wasting cycles thinking about how to code defensively around that possibility, which it has to do constantly in JavaScript.

Sure, you can achieve that goal by replacing runtime exceptions with surprising behavior, but Elm is extraordinarily low on surprising behavior in the grand scheme of programming languages, so I'm honestly not worried about that becoming a problem. :)

[Brian Slesinsky]

What kind of defensive coding did you have in mind? I'm talking about
things that are straight-up programmer errors, and in those cases you
*should* code defensively - that is, don't write code that has a bug
in it! It would be a compiler error if it were possible.

If it's something the caller should actually handle by
pattern-matching against it then the function should return Maybe or
some other type that allows for it.

- Brian

> --
> You received this message because you are subscribed to a topic in the Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-discuss/0K6V1an86iw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to elm-discuss...@googlegroups.com.

[Richard Feldman]

Sure - here's an example of defensive coding in JS: https://gist.github.com/rtfeldman/d6ce6d10e89681901c3c

If you don't remember to do that try/finally, if any of these effects blow up for any reason, the server wouldn't find out that the effect ran at all - plus the subsequent events wouldn't be run either.

It's one thing if that happens because of a catastrophic system failure (e.g. one of the effects runs the system out of memory), but it's another because someone tried to compare two functions for equality. The compiler would tell you if you were accidentally comparing a function to something else, so the odds are pretty good that you actually wanted to do that comparison...and that's not an unrecoverable catastrophic failure; it's just someone making a garden-variety questionable logic choice.

[Evan Czaplicki]

The claim here is that "Elm does have runtime exceptions now". Let's evaluate that claim in context.

Sure, there are ways to make Elm crash. Most of these ways are available in Haskell is well. Does Haskell have runtime exceptions?

What I'm getting at is, Haskell does not give warnings or errors for incomplete pattern matches by default, and yet, I literally never get a runtime error unless I explicitly use (error "...") for some reason. You can say "technically you can get runtime errors" but the point is that it never happens.

I think I am making a practical claim, and it seems pretty clear to me that it is already true in practice. If you think differently, please back up your opinion with claims from other languages that are true or false or dubious and say why and why that is relevant to us.

--

You received this message because you are subscribed to the Google Groups "Elm Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.

[Eitan Chatav]

How about "Practically eliminates runtime errors" instead of "No runtime errors" then? It's more informative about why a user should care as well as more correct.

[Brian Slesinsky]

On Mon, Apr 13, 2015 at 11:25 AM, Evan Czaplicki <eva...@gmail.com> wrote:

> What I'm getting at is, Haskell does not give warnings or errors for
> incomplete pattern matches by default, and yet, I literally never get a
> runtime error unless I explicitly use (error "...") for some reason. You can
> say "technically you can get runtime errors" but the point is that it never
> happens.

Perhaps the best thing to do would be to explain that Elm functions
report errors by returning a value, not by throwing something? The Go
blog had a post along these lines. [1]

It seems like Go and Elm/Haskell don't differ that much
philosophically or practically on errors: they are normal values and
the caller should check for them. The main difference is that Elm and
Haskell have static checking to make sure you actually pattern-match
on the errors, or use some higher-level way of dealing with them like
monads.

In any of these languages, panics are rare, but they do happen, and
when they do you just fix the bug, rather than coding defensively.

This seems like a difference between programming communities (how do
they use exceptions, and what's considered good code) and libraries
(do they throw in practice) rather than a difference between actual
language capabilities. Go does have "panic" and "recover" statements
[2] and they can do the same thing as normal exceptions. By convention
they're never seen in a public API, though a library might panic and
recover internally.

[1] https://blog.golang.org/errors-are-values
[2] http://blog.golang.org/defer-panic-and-recover

[Richard Feldman]

I agree that it's already true in practice; it's certainly been my experience, and I have long since stopped thinking about the possibility of runtime exceptions.

That said, I understand the reluctance to make bold claims when it seems like there's an asterisk involved. I also understand the desire to shrink the asterisk, especially for cases where the change would be essentially harmless - so it would be a win for philosophical consistency with no real corresponding loss.

I don't feel super strongly about that. Independent of philosophical consistency, I'd still want "error on incomplete pattern match" because I'd like to stop double-checking my case expressions whenever I refactor and just let the compiler tell me if I forgot to cover something...but in the other cases mentioned above, I'm only even in favor of changing them for consistency's sake. If I'm being honest, I doubt I'd personally ever notice if they stayed the way they are today.

[Janis Voigtländer]

I’m not seeing people marketing Haskell by claiming it does not have runtime exceptions. Saying that it eliminates lots of runtime errors, or moves them to compile time, etc., maybe even that in practice one usually doesn’t encounter them, yes, but not an unqualified claim that there are no runtime errors at all.

I think the language you use in the 0.15 draft announcement is okay (though Hassan’s list on GitHub shows that one doesn’t have to try that hard to get a runtime error), but this thread here was in reaction to a claim you were proposing for the front page which said that the only way to get a runtime error in Elm is by explicitly calling crash. That was a very literal claim which is easily refuted. (And would likely end up being refuted and thrown in your/our face on Hacker News etc.)

​

[Richard Feldman]

Personally I think Haskell ought to do that. Haskell ought to shout it from the rooftops, as should Elm.

It's a huge deal! It makes scratch-building things easier, makes adding new features on top of existing code bases much easier, and makes refactoring evoke the feeling that you're the Omnipotent Lord of Refactoring. Yet I'm confident making the claim that almost nobody in the dynamic language community has any idea this is something that already exists. I certainly didn't, and I grew up on C++ and Java, which were the only statically type-checked languages I'd ever been exposed to until a few years ago.

Sure, one doesn't have to try that hard to find a literal counterexample of "no runtime exceptions," but one does have to write (apparently) a good bit more production Elm code than I have to actually stumble upon one by accident. Given that, and given Evan's parallel experience in Haskell (which is less hardcore than Elm about avoiding runtime exceptions), I think that claiming "Elm code doesn't throw runtime exceptions" is (A) representative of the experience people should expect, if not a 100% perfectly ironclad money-back guarantee, and (B) a nobler endeavor than downplaying the claim for the sake of strict accuracy.

JavaScript programmers deserve to know this is a world they can live in! It's such an absurdly nicer word, the real shame would be people not finding out it already exists.

[Richard Feldman]

...having said all that, I suppose it wouldn't be the end of the world if the language were "Pretty much the only way to get a runtime exception in Elm" instead of "The only way to get a runtime exception in Elm" ;)

[Joey Eremondi]

For me, part of the reason for the qualifying it now is that, within a week or so, I'll be finished the pattern match checker. I think we could probably have it merged in 0.16, when the claim would be literally true, except for compiler bugs, native bugs, or running out of resources.

On Apr 14, 2015 8:41 AM, "Richard Feldman" <richard....@gmail.com> wrote:

...having said all that, I suppose it wouldn't be the end of the world if the language were "Pretty much the only way to get a runtime exception in Elm" instead of "The only way to get a runtime exception in Elm" ;)

--

[Joey Eremondi]

Just to clarify, this is the same thing I was talking about in this thread: https://groups.google.com/forum/#!topic/elm-dev/-c6weSZjr44

I'm doing it for a school project, so it's possible it will take much more to get merged, or might not get merged at all.

[Alex Shroyer]

Don't serve troll food.  If it's likely for the claim to be true without any asterisks in the near future, then wait.  Take a page from Steve Jobs and maintain secrecy until the "big unveil", and then make a huge deal about it.  For instance, show the 21 (or is it more now?) pages of runtime exceptions GitHub/Atom is experiencing, and similar examples from other languages.  Make the casual reader from Hacker News go "whoa".

On the other hand, if the asterisks are going to stay, but they're honestly not a big deal, then just say so.  If you can quantify the reduction in runtime exceptions (Richard, do you have numbers?) then put those up.  Likewise, if the (rare) runtime exceptions are easy to find (i.e. not Heisenbugs) then put that up too.

[Richard Feldman]

The number is zero. :) I have yet to write any Elm code that throws a runtime exception.

The number for CoffeeScript? Enormous, as per usual for that sort of development, but I have not been keeping track. It's not like you can get bigger than an infinityfold increase, though.

[Janis Voigtländer]

Others’ experience can be different, specifically beginners’ experience. Maybe read this thread up to the end. I remember at least one other problem that came to the list as “my code stops running” which ultimately boiled down to the same issue as in that thread. You must be a very disciplined programmer if you never forget to handle some case in a pattern match. But it is that discipline, not (currently) Elm per se, which saves you there.

All the more reason to hope that Joey’s totality checker will be a success!

​

2015-04-14 14:42 GMT+02:00 Richard Feldman <richard....@gmail.com>:

The number is zero. :) I have yet to write any Elm code that throws a runtime exception.

The number for CoffeeScript? Enormous, as per usual for that sort of development, but I have not been keeping track. It's not like you can get bigger than an infinityfold increase, though.