Warn on Debug.crash

[Zachary Kessin]

The Debug.crash function is a great tool for a placeholder for code that does not yet exist. But what would be really good is if there was a way to have a compiler flag to treat it as a build error. So that I can use it as a placeholder, but my build chain can ensure that it does not hit production.

What do people thing?

--

Zach Kessin

Your CRM Link

Twitter: @zkessin

Skype: zachkessin

[Peter Damoc]

This is a really good idea. 

The use of Debug.crash could be a warning and if we get --werror , that could be used for production. 

--
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.

--

There is NO FATE, we are the creators.
blog: http://damoc.ro/

[Fedor Nezhivoi]

In this case you would never compile with, for example StartApp.Simple https://github.com/evancz/start-app/blob/2.0.2/src%2FStartApp%2FSimple.elm#L96

Best regards,

Fedor Nezhivoi.

[Zachary Kessin]

Good point, maybe just use a grep for that :)

Zach

ᐧ

[Peter Damoc]

The code could be changed to return the model on Nothing but this example made me curious.

Are there valid cases where one would have to use Debug.crash outside of debugging? 

[Max Goldstein]

I use it in my nonempty list library. I've written fairly exhaustive property-based tests to confirm my reasoning that these things really can't happen. In particular:

• indexing into a list at a known-valid index
• sorting never changes the length of the list, and I know the list I pass it isn't empty

I really don't want to throw Maybes into the API because the whole point of nonempty lists is that you can avoid Maybes in a safe way.

Even in Haskell there are invariants that can't be expressed in the type system, and so much more so for Elm. Requiring exhaustive case analysis is great, but there needs to be an escape hatch.

[Joey Eremondi]

I think we need Debug.Crash for incomplete code, and Debug.impossible for the cases Max is talking about. Identical behaviour, buy we could consider one unfit for release code.

I also am working on a static analysis tool that would help find out if crash uses could ever actually be called, but it's nowhere near ready.

--

[Max Goldstein]

I would be okay with a separate Debug.impossible, except that core uses crash in a case that isn't impossible: Signal.mergeMany []. This crashes with the explanation that it was given an empty list.

Ultimately, you're trusting the package author to do good work. Not abusing Debug.crash falls into that, as does not blowing the stack and crashing that way. Is crashing really so much worse than all the other ways a module could be crud?

I don't think static analysis will be able to understand the examples in nonempty-list, much less mergeMany.

**** totally off-topic idea for not needing Debug.crash in mergeMany ****

List.Nonempty is merged into core. List syntax can be used to represent a literal array or nonempty list as necessitated by type constraints; defaults to list; [] :: Nonempty a fails at compile time. Now mergeMany can demand a nonempty list without any change at the call site.

[Ossi Hanhinen]

What do you think about a specific syntactic feature for not-yet-implemented function, e.g.

difficultFunction : Thing -> Another -> Task Error Success

difficultFunction =

  ???

[Zachary Kessin]

How about a Debug.incomplete or something that works like Debug.crash but can generate a warning. 

Zach

ᐧ

--

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.

[Joey Eremondi]

I like what Haskell does with typed holes, since they tell you the type of the value you need to fill the hole.

[Zachary Kessin]

> I like what Haskell does with typed holes, since they tell you the type of the value you need to fill the hole.

Could you explain how it works, for those of us who are not haskell developers

Zach

ᐧ

[Joey Eremondi]

@Max

 

I don't think static analysis will be able to understand the examples in nonempty-list, much less mergeMany.

Actually, the mergeMany example is exactly the kind of thing the analysis does: seeing that a non-empty list never gets passed to the function, and verifying that the empty-branch of the pattern match never gets taken.

If you're curious, there's an extended abstract that I did for a Student Research Competition, but it's far from complete, and the code is still a major WIP.

--

[Joey Eremondi]

@Zachary:

There's a wiki page and Haskell Doc on typed holes.

What Haskell does is, you can replace any expression with "_". It will then typecheck the code as if there was something there, and report the types of values you need to fill in your holes.

Right now, it just typechecks with holes, but I think there's an option where it will actually compile your code and throw an error if you ever try to evaluate a hole.

The biggest problem right now is that, at least in my experience, you can't import a module with holes, but maybe that wouldn't be a problem if you defer the errors until runtime.

[Fedor Nezhivoi]

Debug.impossible sounds really great to me