Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upRuntime error with recursive definitions #1591
Comments
elm
locked and limited conversation to collaborators
May 9, 2017
evancz
added
the
meta
label
May 9, 2017
evancz
changed the title from
Runtime error with mutually recursive definitions
to
Runtime error with recursive definitions
May 9, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
evancz
May 16, 2017
Member
This is probably fixed by e2a5157.
I checked some cases of my own, but I have not yet tested the cases listed here. It is very difficult to build the compiler right now, so this is not something it'll be easy for anyone to check on a whim. Putting on my pre-release checklist.
|
This is probably fixed by e2a5157. I checked some cases of my own, but I have not yet tested the cases listed here. It is very difficult to build the compiler right now, so this is not something it'll be easy for anyone to check on a whim. Putting on my pre-release checklist. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
evancz
May 23, 2018
Member
I outlined a more general approach here, and it is implemented in development builds. All of the examples with SSCCE in this thread work with the new code. Hopefully this is the real deal!
|
I outlined a more general approach here, and it is implemented in development builds. All of the examples with SSCCE in this thread work with the new code. Hopefully this is the real deal! |
evancz commentedMay 9, 2017
•
edited
Edited 1 time
-
evancz
edited May 17, 2017 (most recent)
When writing mutually recursive definitions, it is possible to end up with runtime errors. This is most common with complex
DecoderorParserdefinitions, and can often be resolved by introducingDecode.lazyorParser.lazyto delay evaluation of certain things.Good Examples: #1516, #1527, #1529
No SSCCE:
#1575,#1560,#1562Something Else: #1584
Explanation
Thanks to #873, Elm is able to detect certain forms of bad recursion. For example, it can catch the following:
It detects cases when the recursion is unmediated by a lambda. That means Elm cannot detect cases like these:
Some of these functions will loop infinitely and some are fine. The point is that we do not know of a general and efficient strategy that can successfully rule out "bad" recursion more often. If you have a plausible idea, please write it up and share it on elm-dev.
The actual problem in many cases is that there exists a way to define the values, but it is not being used.
Ideas
Issue #1580 proposes a rather elaborate fix, at least as written. Needs to be distilled down.
Aside from that, this problem may be exacerbated by the fact that code gen produces functions in very particular ways to make currying faster.
This means that values that use
fbefore the definition will not be able to findfand crash. We can move all function definitions above all value definitions. This may help with some subset of the issues folks are seeing, but it is not a complete solution.