All Unkept
Posted in: Haskell, Web development  —  4 July 2009

GHC bug?

What do you do when you are dealing with what seems like a bizarre compiler bug, with the compiler being nothing less than GHC? First, pinch yourself — check; then try again, 3 times to be sure — check; clear out 'dist/' and any temporary build files — check; sleep on it — check.

And it's still happening.

I'm trying to use HStringTemplate for my personal blog software, in particular the renderf function. I was getting tricky compilation errors, and in the course of messing around I found the following:

GHC cannot compile a certain function, call it func1 for now, which uses renderf. But it compiles and works just fine if another function func2 (which doesn't use renderf, but does use a related HStringTemplate function render) is present in the module, even though func2 is not used anywhere in the project. Changing some of the details of what func2 does causes compilation to fail again, though other details can be changed.

That has to be impossible, right? Am I losing my mind?

Ideally I'd create a nice simple test case, but that might take hours, and changing small things about the voodoo function func2 seems to destroy its magical properties, and I'm suspecting the problem is in me. So I'll just post all my code. The bad news is there are lots of dependencies. The good news is I have used cabal, so the following instructions should suffice if you have cabal installed.

Download and install 'ella' (CGI web framework I'm writing) and dependencies:

hg clone -r 30aa625a3f51 http://bitbucket.org/spookylukey/ella/
cd ella/
cabal configure --user && cabal build && cabal install --user
cd ..

(You can download a tarball if you don't have mercurial)

Download and build the blog software:

hg clone -r e1015168e56b http://bitbucket.org/spookylukey/haskellblog/
cd haskellblog/
cabal configure --user && cabal build

(Again, download the tarball if you don't have mercurial)

The build should succeed. Now, the voodoo function is at the end of src/Blog/Views.hs. Comment it out:

perl -pi -e 's/this_is_not_used/-- this_is_not_used/' src/Blog/Views.hs

Build again:

cabal build

Result - this compilation error.

I don't know whether that compilation error is correct or not, but either way, it seems crazy that it could depend on the existence and implementation of a completely unused function.

For reference, I'm using GHC 6.10.1.

Any ideas?

Comments §

§ On 4 July 2009, luke wrote: 442
I see the same with GHC 6.10.3, BTW. I've just installed that from source, and freshly installed all the dependencies of the above software, so I think I can rule out some kind of borked installation.

§ On 4 July 2009, daniel wrote: 443
hi, i didn't look the error in much detail, but keep in mind that the *type signature* of func2 might be important. does it still compile if you replace the body of func2 with undefined?

§ On 4 July 2009, Anonymous Coward wrote: 444
It's correct in its own way. Note that if you add -XNoMonomorphismRestriction you still get the error even with this_is_not_used uncommented. This surprising behavior where deleting code can cause errors in unrelated code is why the monomorphism restriction is bad.

You can get rid of the problem by giving get_template a type signature. get_template :: String -> IO (StringTemplate ByteString). With the monomorphism restriction, this_is_not_used gives get_template this concrete type.

The problem is that the StringTemplate's Stringable type parameter isn't specified and the type system doesn't know that (([Char], [(Blog.Category.Category, [Char])]) -> ([Char], Bool) -> ByteString) is never going to be Stringable.

§ On 4 July 2009, sclv wrote: 445
quick suggestion -- give an inline type signature to the various arguments and see if the issue goes away.

§ On 4 July 2009, Anonymous Coward wrote: 446
The error message should certainly be improved. If you comment out get_template AND categoriesView, you get a much better error:

Blog/Views.hs:57:22:
    Ambiguous type variable `a' in the constraint:
      `Stringable a'
        arising from a use of `getStringTemplate' at Blog/Views.hs:57:22-53
    Possible cause: the monomorphism restriction applied to the following:
      get_template :: String -> IO (StringTemplate a)
        (bound at Blog/Views.hs:55:0)
      get_templates :: IO (STGroup a) (bound at Blog/Views.hs:50:0)
    Probable fix: give these definition(s) an explicit type signature
                  or use -XNoMonomorphismRestriction


§ On 4 July 2009, Anonymous Coward wrote: 447
Sorry, I meant this_is_not_used and categoriesView

§ On 4 July 2009, luke wrote: 448
A type signature on get_template did it - thanks! I've been bitten by the monomorphism restriction before, but never as badly as that. It was the completely unrelated error message that foxed me.

Thanks again for the time and effort spent in debugging this for me :-)

Add comment

Format:

  • Javascript has to be on to get past my spam protection, and cookies, and there is a delay, sorry for any inconvenience!
  • I reserve the right to moderate comments.