Haste-0.6: Documentation/clarification required: Module top-level items.

[WolframKahl]

I lost half a night of sleep over the following problem, until I gave up and ran my exam (I know I am daring, but Haste is just too good!) with less functionality than hoped for: In my Main module, I have a big record that contains, among other things, a number of remote $ static (import_ $ ... calls, either directly as fields, or slightly deeper down. I refactored one of these into top-level functions, as I had done previously in other cases successfully, one for the part outside the remote, and one for the remote, and then got run-time errors: With some arrangements:

CalcCheckWeb: too few arguments to remote function

, but mostly

CalcCheckWeb: user error (Pattern match failure in do expression at src/Haste/App/Remote.hs:51:5-12)

I played with this a bit more today: I am only refactoring, and not changing anything, and still get that effect: It works with everything inside the record field, but not after refactoring.

As I have previously observed mess-up when I had #ifdef-ed top-level items present only for GHC, but not for HASTE, I now conjecture that GHC is inlining away my factored-out functions, and producing that same kind of mess-up.

I have not investigated enough to be certain that my explanation is right, but I am seeing “superfluous” top-level definitions all over the Haste/Haste-App source, so there must be something in this direction.

In my opinion, this deserves being documented prominently...

[valderman]

This does indeed sound like GHC is inlining away the functions, but that shouldn't happen with functions that have a static pointer pointing to them. I think this should be fixed rather than documented.

Does putting NOINLINE pragmas on the affected functions make the problem go away? Do you have a minimal example which triggers this that you're able to share?