Generated JS blows up at runtime due to vars placed in the wrong order

[JoshCheek]

Using Elm 0.15.1

This example blows up at runtime:

import Json.Decode exposing (..)
import Graphics.Element

main            = Graphics.Element.show parsed
parsed          = decodeString decodeByKind "{\"kind\":\"parent\",\"value\":{\"kind\":\"child\",\"value\":1}}"
decodeByKind    = "kind" := string `andThen` chooseDecoder
chooseDecoder k = if k == "child" then decodeChild else decodeParent
decodeChild     = "value" := int
decodeParent    = "value" := decodeByKind

When compiling with elm make --output BrokenJson.html BrokenJson.elm This generates the following js at line 3205 (reformatted slightly to be easier to read). When the two variables are swapped around, it then works correctly.

var decodeByKind = A2($Json$Decode.andThen,
A2($Json$Decode._op[":="],
"kind",
$Json$Decode.string),
chooseDecoder);
var chooseDecoder = function (k) {
   return _U.eq(k,
   "child") ? decodeChild : decodeParent;
};

---

Not sure if it's relevant, but my elm-stuff/exact-dependencies.json is:

{
    "evancz/virtual-dom": "2.0.0",
    "evancz/elm-http": "1.0.0",
    "evancz/start-app": "1.0.1",
    "evancz/elm-html": "4.0.1",
    "elm-lang/core": "2.1.0"
}

[JoshCheek]

Also. Not sure if this is expected behaviour or not, but for a couple hours I couldn't get any decent feedback on why it was blowing up until I took out the HTTP request and mailbox.

If you compile this code in the same environment as the one above:

import Http
import Json.Decode exposing (..)
import Graphics.Element
import Task exposing (Task)

main            = Signal.map Graphics.Element.show receiveParsed.signal

receiveParsed   = Signal.mailbox initialValue
initialValue    = Ok -1

port parseJson  : Task Http.Error ()
port parseJson  =
  Http.post decodeByKind "http://localhost:3004" (Http.string "1.a")
    `Task.andThen` report

report parsed   = Signal.send receiveParsed.address (Ok parsed)
decodeByKind    = "kind" := string `andThen` chooseDecoder
chooseDecoder k = if k == "child" then decodeChild else decodeParent
decodeChild     = "value" := int
decodeParent    = "value" := decodeByKind

And then run it against this server, the initial value will stay at Ok -1 and nothing will give any indication that it even attempted to parse it.

echo -n $'HTTP/1.1 200 OK\r\nContent-Type: application/json\r\nContent-Length: 52\r\nAccess-Control-Allow-Origin: null\r\n\r\n{"kind":"parent","value":{"kind":"child","value":1}}' | nc -l 3004

If you then consolidate chooseDecoder into decodeByKind, and run the server again, it will correctly parse 1

decodeByKind    = "kind" := string
                    `andThen`
                    \k -> if k == "child" then decodeChild else decodeParent

[JoshCheek]

Also. Not sure if this is expected behaviour or not, but for a couple hours I couldn't get any decent feedback on why it was blowing up until I took out the HTTP request and mailbox.

If you compile this code in the same environment as the one above:

import Http
import Json.Decode exposing (..)
import Graphics.Element
import Task exposing (Task)

main            = Signal.map Graphics.Element.show receiveParsed.signal

receiveParsed   = Signal.mailbox initialValue
initialValue    = Ok -1

port parseJson  : Task Http.Error ()
port parseJson  =
  Http.post decodeByKind "http://localhost:3004" (Http.string "1.a")
    `Task.andThen` report

report parsed   = Signal.send receiveParsed.address (Ok parsed)
decodeByKind    = "kind" := string `andThen` chooseDecoder
chooseDecoder k = if k == "child" then decodeChild else decodeParent
decodeChild     = "value" := int
decodeParent    = "value" := decodeByKind

And then run it against this server, the initial value will stay at Ok -1 and nothing will give any indication that it even attempted to parse it.

echo -n $'HTTP/1.1 200 OK\r\nContent-Type: application/json\r\nContent-Length: 52\r\nAccess-Control-Allow-Origin: null\r\n\r\n{"kind":"parent","value":{"kind":"child","value":1}}' | nc -l 3004

If you then consolidate chooseDecoder into decodeByKind, and run the server again, it will correctly parse 1

decodeByKind    = "kind" := string
                    `andThen`
                    \k -> if k == "child" then decodeChild else decodeParent

[evancz]

Is this a version of elm/compiler#873? Are all the pieces of the original example needed to replicate the error?

[evancz]

Is this a version of elm/compiler#873? Are all the pieces of the original example needed to replicate the error?

[JoshCheek]

Is this a version of elm/compiler#873?

I don't think so. That sounds like it's about lazy data structures. I very intentionally removed as much complexity as I could, so the data structure is only an Int now. It also works if you tweak it any of about 10 different ways.

If I had to guess, I'd assume there's some path that expected a function to be wrapped around the call so that the order of the variable definitions didn't matter. Other thing that seems potentially likely would be something to do with the native implementations of the JSON lib. Or possibly some edge case in how it resolves which functions depend on which ones.

Are all the pieces of the original example needed to replicate the error?

Yeah, you can paste that first example into http://elm-lang.org/try and see the same result. eg

[JoshCheek]

Is this a version of elm/compiler#873?

I don't think so. That sounds like it's about lazy data structures. I very intentionally removed as much complexity as I could, so the data structure is only an Int now. It also works if you tweak it any of about 10 different ways.

If I had to guess, I'd assume there's some path that expected a function to be wrapped around the call so that the order of the variable definitions didn't matter. Other thing that seems potentially likely would be something to do with the native implementations of the JSON lib. Or possibly some edge case in how it resolves which functions depend on which ones.

Are all the pieces of the original example needed to replicate the error?

Yeah, you can paste that first example into http://elm-lang.org/try and see the same result. eg

[evancz]

Okay, so this is valid code, not like elm/compiler#873, but it points out an issue in code generation. I'm going to add a note to elm/compiler#873 about this and try to tackle them both at the same time.

Thanks for the report!

[evancz]

Okay, so this is valid code, not like elm/compiler#873, but it points out an issue in code generation. I'm going to add a note to elm/compiler#873 about this and try to tackle them both at the same time.

Thanks for the report!