tl;dr
Here is a reproduction that mimics the code I was writing when I stumbled across this:
https://github.com/dustinfarris/elm-ctor-bug
I think elm is missing a reference to an undefined variable when a variable of the same name is being used nearby.
Here is the relevant excerpt from the reproduction.
1 addPeople : List Person -> Dict String Person -> Dict String Person
2 addPeople newPeople currentPeople =
3 let
4 people =
5 newPeople
6 |> List.foldl
7 (\person acc ->
8 people
9 |> Dict.update person.id (mergePeople person)
10 )
11 currentPeople
12 in
13 people
You can see that foldl func labels the accumulator as acc (line 7), but in the implementation it references people (line 8). people does not exist in this scope, but the compiler is not catching that. This seems to be because the result of foldl is being assigned to another variable also called people (line 4).
If line 4 is changed to something else, like newPeople, then the compiler will throw the expected error: NAMING ERROR : Cannot find variable 'people' on line 8
Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!
Here is what to expect next, and if anyone wants to comment, keep these things in mind.
It seems you do not unterstand how scoping works in Elm. Due to how let-expressions work, the variable "people" bound there does exist in the scope of the lambda expression passed to foldl. The compiler would be wrong to complain that "people" does not exist.
@jvoigtlaender you're right, i am not an expert on all of this.
What I can tell you is that the above code compiles, and then throws a runtime error.

Yes. And the reason is the same as why a definition like let list = foldl (\_ _ -> list) [] [0] in ... would lead to a runtime error. It causes infinite recursion (nothing to do with a scoping error on the compiler's part), which is impossible to prevent for the compiler in general. It's like writing a never-terminating while-loop in a language like C or Java: some programmer errors are impossible to detect for a compiler in general.
@jvoigtlaender ok, so is this actually related to https://github.com/elm-lang/elm-compiler/issues/873 then?
Yes, in so far as the fix that was implemented in Elm 0.18 to partially address #873 made it so that, for example,
let xs = 1 :: xsis now rejected by the compiler, but did not go so far as to also reject
let xs = (\x -> x :: xs) 1or
let list = foldl (\_ _ -> list) [] [0]or indeed
The overarching reason being that it is mathematically impossible to mechanically detect all the cases that are semantically as bad as the syntactically easily detected xs = 1 :: xs one.
There has to be a line drawn up to where the compiler tries to detect such semantic circularities. At the moment, that line is drawn between the first bullet point above and all the others.
@jvoigtlaender got it. thanks for the quick feedback on this鈥攊 now know what to check for if i see this sort of error in the future.
@rtfeldman is this included in your list of runtime exceptions
Infinite recursion/stack overflow - this is a Comp Sci problem, not an Elm problem
should I just close, or is there something actionable with my specific scenario?
I don't think it's included in that list, no. But it should be!
If possible, it would be great if you could boil this down to a SSCCE, open a new issue with the SSCCE, and then link to this issue (and close this issue) from the SSCCE one. Then I can link to that one in https://github.com/elm-lang/core/issues/377
Does that seem reasonable?
@rtfeldman does the example repo i listed in the description qualify?
It's close! It's not self-contained, though, and it's not quite minimal yet. 馃檪
See if you can take that code and reduce it to something that you can post on Ellie where someone else can hit Compile and immediately see the runtime exception.
Got it! I'll work on this and open a new issue. Thanks for the guidance.
Thanks for helping isolate this! 鉂わ笍
Most helpful comment
Got it! I'll work on this and open a new issue. Thanks for the guidance.