Arity expansion not working right

[simonpj]

With GHC 6.10, the arity of GHC.Handle.openFile is reported as 2. But its definition is

  openFile fp im = Prelude.catch (...) (...)

and Prelude.catch has arity 3. Somehow openFile isn't getting eta-expanded properly.

It's not a huge deal, but arity expansion is an important optimisation so I want to track places it isn't happening.

[batterseapower]

This is happening because at the time we compile GHC.Handle, the Prelude module has not yet been compiled. This means that Prelude.catch is pesimistically assumed to have an arity of 0, so openFile can only have an arity as large as the number of leading lambdas it has - i.e. 2.

I don't think there is a clean solution for this without whole-program compilation.

[simonpj]

Ian: Max is right. Prelude does export catch, and there is a Prelude.hs-boot.

But maybe that isn't needed any more, with the new exception story. After all, catch now seems to be defined in Control.Exception.Base, and all Prelude does is say

  catch = Control.Exception.Base.catch

which is not clever, because it pulls the defn of catch higher in the module graph.

• Can you see if this particular module loop can be broken?
• More generally, do you have a description of the intended module structure of base? Something like this: ModuleDependencies. It's very hard to unravel by just looking at the code.

I'll assign this to you to look at!

Simon

[simonpj]

Fixed by

  * Move some catch definitions around to avoid an import loop
  As suggested by simonpj in trac #2822.

    M ./Prelude.hs -27 +1
    R ./Prelude.hs-boot
    M ./System/IO/Error.hs -2 +27

Thanks, Ian.

Simon