elm-lang.org brought down by infinite loop in compiler

[joeyadams]

I was playing around in elm-lang.org's interactive IDE, trying to make a draggable circle. In particular, I was going for something like this:

dragCircle :: Number -> (Number, Number) -> DragCircle
type DragCircle = (Form, (Number, Number) -> Bool -> DragCircle)
    -- note the infinite type

Then, use foldp and lift2 (,) position isDown to feed the DragCircle automaton.

I ended up crashing the server. I compiled elm-server locally and reproduced the hang and leak. Here's a minimal code sample triggering the leak:

move pos down = rest
rest pos down = if down then move else rest

I suppose such hangs could be avoided using System.Timeout in elm-server, e.g.:

  mhtml <- liftIO . timeout 10000000 . evaluate $ Elm.toHtml libLoc (pageTitle filePath) content

I don't know if happstack-server does anything to time out response generation or not.

Another thing you could do is set the maximum amount of memory the runtime system may allocate, by adding this to the .cabal file:

ghc-options: -rtsopts -with-rtsopts=-M512m

This way, if elm-server blows up again, it doesn't bring the whole system to a crawl.

[evancz]

Thanks for the report! The server is back up, and I'll work on figuring this one out. The type you describe is recursive, not infinite (I think this is a standard distinction, not sure though). The point is that the type of DragCircle can be written down with a finite amount of characters. This sort of thing should type-check, but I'll look into this more.

The mutually recursive functions you define (move and rest) actually have an infinite type:

move :: (Int,Int) -> Bool -> ( (Int,Int) -> Bool -> ( (Int,Int) -> Bool -> (...) ) )

I should be detecting this and throwing an error, but I guess not in this case!

Were you also seeing this behavior on functions that did not have infinite types?

[joeyadams]

Were you also seeing this behavior on functions that did not have infinite types?

I don't think so. I'm pretty sure dragCircle had an infinite type. Going by my definition above:

dragCircle :: (Form, (Number, Number) -> Bool -> (Form, (Number, Number) -> Bool -> (Form, (Number, Number) -> Bool -> ...)))

I used type in the Haskell sense, meaning a type alias. Does Elm treat type differently?

Also, note that if you change the offending code sample to:

move pos down = rest
rest pos down = (move, rest)

It doesn't crash, it just accepts the code (which Haskell rejects due to an occurs check failure).

[joeyadams]

To clarify, I didn't use the type keyword in the actual code. The type signatures I gave were the types I was expecting the code to have.

[evancz]

Ok, makes sense. I was treating type as data in my mind. I'll work on this!

[joeyadams]

I found a more innocent-looking piece of code that blows up the compiler:

f = foldr1 (:) [1..10]

The problem is that the Elm compiler does not seem to implement an occurs check. Namely, when unifying types, and you have a situation like this:

unify a [[a]]

This should be treated as a type error, since the substitution a ==> [[a]] forms an infinite type.

In general, when unifying a type variable a with type T:

• If T is the type variable a, no need for a substitution.
• If T contains the type variable a (e.g. [a], Maybe a, a -> Int), produce an "occurs check" error.

Typing Haskell in Haskell, section 6 describes unification and matching algorithms pretty nicely.

[evancz]

I am pretty certain you are correct, and I believe this can be corrected pretty easily. I'll take a look now.

I'll take a read through the link you provided to see if I can clean things up / find other mistakes!

[evancz]

Ok, fixed and pushed to master!

[evancz]

Released!