Hi,
I’m migrating 0.18 code to 0.19 and I’ve encountered “bad recursion” for inner recursive function. As a solution I try to move it to top level function, but compiler shows some internal error:
~/w/elm/elm-tichu$ elm make src/ServerMain.elm --output server_main.js
elm: Map.!: given key is not an element in the map
CallStack (from HasCallStack):
error, called at ./Data/Map/Internal.hs:610:17 in containers-0.5.11.0-K2TDqgYtGUcKxAY1UqVZ3R:Data.Map.Internal
elm: thread blocked indefinitely in an MVar operation
~/w/elm/elm-tichu$ elm make src/ServerMain.elm --output server_main.js
elm: You ran into a compiler bug. Here are some details for the developers:
msg [rank = 1]
Please create an <http://sscce.org/> and then report it
at <https://github.com/elm/compiler/issues>
CallStack (from HasCallStack):
error, called at compiler/src/Type/Solve.hs:205:15 in main:Type.Solve
elm: thread blocked indefinitely in an MVar operation
I got a load of these when I refactored the data structures I used in some 1.9 code. The only way I found I could get around it was to delete all the code in the module and add it back a function at a time and make sure it compiled as I built it up. I did occasionally have to clear out my elm-stuff folder whilst I went along too.
I noticed you are using lots of type variables in your existing function signatures, e.g. msg as opposed to types, custom types, or type aliases, e.g. Msg? If you don’t absolutely need type variables, then perhaps change to regular types. (I have just noticed that often folks use type variables in Elm when they don’t need to or mean to. It can also make it harder to figure out what is happening with the code.) Again, I just glanced through your code, so these may be necessary!
I would imagine these two changes would make easier for the compiler to figure out what you are doing (or want to do!).
After looking into compiler’s code I think you may be right as
~/w/elm/elm-tichu$ elm make src/ServerMain.elm --output server_main.js
elm: You ran into a compiler bug. Here are some details for the developers:
msg [rank = 1]
suggest that compiler could not handle free variable (msg) in top level recursive function. This variable is not resolved in module that declares function but in module that depends on it.
Removing free variable is possible here so I’ll try to refactor it to verify this assumption.
This issue https://github.com/elm/compiler/issues/1789 looks like possibly same bug. It contains no recursion, so maybe I was wrong assuming recursion has something to do with it. SCCE attached to the issue:
module Minimal exposing (..)
import Element exposing (..)
import Element.Background as Background
import Element.Events exposing (onClick)
import Element.Font as Font
lighterBlue =
rgb255 1 1 1
navChoice : mode -> (mode -> msg) -> mode -> String -> Element msg
navChoice currentmode mode txt mmsg =
if currentmode mode then
el [ Font.bold, onClick (mmsg mode) ] (text txt)
else
el [ onClick (mmsg mode) ] (text txt)
navbar : mode -> (mode -> msg) -> List ( mode, String ) -> Element msg
navbar currentmode mmsg choices =
row [ Background.color lighterBlue, spacing 5, alignTop, padding 5, width fill ]
(List.map (\( s, m ) -> navChoice currentmode mmsg m s) choices)
I actually never use type variable as I just find it makes the code confusing more often than not, as you can name them anything and yet they mean nothing!
I get that they are useful for generic functions like List, Task, etc.
I’d just rather have to be specific and use a custom type (aka Union Type) or a type alias, that way I know what I’m passing around. It forces you to be clear about what you are doing and makes the code much easier for someone else to understand.
Anyway, hope that your code is such that you are able to re-factor w/o type variables!