Elm Suggestion : Type declarations on closures

[jadski]

Elm's error messages on functions are great.

However when the compiler finds fault within a function let statement, it's reported as an error between lines X and Y - basically the error pertains to the entire let statement, which is treated as a single expression (and may contain many closure assignments and sub-assignments).

This can cause mayhem when trying to find a problem in a function hosting several (possibly nested) closures.

It's often natural to write a function straight up including it's closures (particularly when experimenting with Elm), but on several occasions I've found myself having to unwind the thing piece by piece to try and find an error.  Ultimately I end up with a module polluted with a large number of small, out of context functions that don't belong there - and I've lost the nicety of closures. What's more, I'm afraid to place this confetti back into it's original box, in case more tinkering requires me to repeat the process.

I've pretty much banned all but trivial closures from my code now as a result - only to avoid the pain of hunting down an error.

Type declaration for closures, or improved targeting of error messages would resolve this. I think they would save people (like me at least) plenty of time, and provide confidence developing with closures.

Are either of these on the Elm roadmap?

They would definitely make my code prettier.

[Joey Eremondi]

I'm doing a project this summer looking at making type-error messages a lot friendlier. We'll definitely add this to the list of error messages to improve!

For the declarations, I think you can do this already. The trick is that you have to do it in a let statement.

Something like this:

import List

myFun : List (List Int)
myFun =
  let
    nonNulls : List (List a) -> List  (List a)
    nonNulls = \list -> List.filter (not << List.isEmpty) list
  in nonNulls [ [1,2,3], [4], [], [5,6,7] ]

It's maybe more verbose than what you're thinking, but it's certainly better than putting them all at the top-level.

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

[Jeff Smits]

It's maybe more verbose than what you're thinking, but it's certainly better than putting them all at the top-level.

I disagree. If you can easily put your helpers on the top-level, then that’s great; as long as you don’t export them, there is no pollution. There is also less clutter with let-in, no indentation, no questioning why this is a nested helper function, maybe there is some shadowing going on. Top-level definitions are much simpler to read. The shorter and sweeter the top-level definitions are, the better I like the code. Of course this is a style preference…

[jadski]

Joey,

 thanks for the example - I feel better already. This nugget of info should go into the Syntax docs...

[Evan Czaplicki]

Jadski, I've definitely seen errors like this, but I don't have a piece of code that triggers it in https://github.com/evancz/error-message-catalog It may be possible to be more specific, but we need a way to diagnose the root issue.

Do you happen to have an example on hand? If so, can you open a PR to add it?

--
Sent from Gmail Mobile

[jadski]

I've created a PR for this

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

For more options, visit https://groups.google.com/d/optout.

[jadski]

PS: I also created one for elm-svg, demonstrating the virtual-dom interfering with svg node discovery