Internal compiler error for recursive Task composing function

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-
elm: thread blocked indefinitely in an MVar operation

You can see function after migration here:

It is quite complex, I admit. In general it composes http requests (with retry composition), Process.sleep and recursively itself:

I post it here hoping maybe it will help tracing compiler bug. If any additional data would help, I’ll try to add it to this thread - just ask.

If someone found same issue and has a solution, I would be glad to test it on this code. As for today I’m lacking idea how could it be fixed.


After doing some splitting ( I came to this:

~/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 <> and then report it
at <>

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.

My two thoughts are:

  1. Add function signatures to every function.
  2. 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!).

Best of luck!

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 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)
        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 ]
        ( (\( s, m ) -> navChoice currentmode mmsg m s) choices)

Yeah, cool.

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!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.