Inconsistent compiler behaviour, adding an identity function leading to different outcome

[FRosner]

Problem

When a locally bound function and a global function have the same name f, then using it as f () or (identity f) () yields different results.

Context

I was trying to implement an ADT representing a circular list. This is what I had so far:

module CircularList exposing (CircularList(..), get, next)


type CircularList a
    = CircularList { val : a, next : () -> CircularList a }


get : CircularList a -> a
get (CircularList { val, next }) =
    val


next : CircularList a -> CircularList a
next (CircularList { val, next }) =
    -- it doesn't work when I just do "next ()"???????
    (Debug.log "next" next) ()

It works as expected and the following test case is green:

test "get" <|
            \() ->
                let
                    s =
                        "bla"

                    a =
                        CircularList { val = s, next = \() -> a }
                in
                    Expect.equal s (CircularList.get (CircularList.next a))

However as soon as I remove the Debug.log and execute next () directly the test never finishes. Looks like the identify call makes the compiler use the locally bound variable, while without, it takes the global function.

See slack discussion for more details.

Environment

• Elm Version: 0.18.0
• NPM Version: 5.0.3
• OS: Mac OS Sierra 10.12.6

Workround

Don't name the local variable the same as the global.

Expected Behaviour

• The behaviour should be consistent whether I add identity or not
• The compiler should warn because I am shadowing the global name (or not)
• If the behaviour cannot be made consistent the code should not compile, forcing you to choose different names

[process-bot]

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.

[process-bot]

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.

[matekdk]

It seems that debug statement is getting hold of the argument-next from the argument, while the execution of the method is calling the self-next method instead.

I think that in this case, the compiler should err with a message that there are two different "next" entities in the scope, and it does not know which one to choose.

[matekdk]

It seems that debug statement is getting hold of the argument-next from the argument, while the execution of the method is calling the self-next method instead.

I think that in this case, the compiler should err with a message that there are two different "next" entities in the scope, and it does not know which one to choose.

[zwilias]

The type-checker and the codegen disagree, leading to an incorrect result. The inner-most next should be the one used, which the type-checker does, but the codegen seems to think this is a recursive function and transforms it to a while loop instead.

@FRosner could you close the issue here and reopen it on elm-lang/elm-compiler instead? Thanks for the report!

[zwilias]

The type-checker and the codegen disagree, leading to an incorrect result. The inner-most next should be the one used, which the type-checker does, but the codegen seems to think this is a recursive function and transforms it to a while loop instead.

@FRosner could you close the issue here and reopen it on elm-lang/elm-compiler instead? Thanks for the report!

[jvoigtlaender]

I think this is a known and reported issue.

elm/compiler#1452

[jvoigtlaender]

I think this is a known and reported issue.

elm/compiler#1452

[FRosner]

I opened elm/compiler#1636 instead.

[FRosner]

I opened elm/compiler#1636 instead.