RE: Latest External Core bugs

[Simon Peyton-Jones]

| External Core is totally broken in the HEAD, due to the change in the | representation of top-level bindings. The parser expects all top-level bindings | to be unqualified, but GHC still generates bindings with qualified names | for Main.main and :Main.main. If the parser is changed to ignore the module | names in these cases, compiling external Core files still fails, since the | definition of :Main.main refers to Main.main (which is now just "main"), and | there are two definitions for "main". I tried to fix it, but my brain melted.     Well at least I can explain what is going on.  I've added a section to the Commentary to explain, and I append it below.   It’s less obvious how to fix it.  Even if we added back in the module name in the function defs etc (which seems rather overkill) so that :Main.main was distinct from Main.main, there’s still the issue of generating the module initialisation.   I rather think the best thing is to hack the ExtCore part.   Maybe we could a)     not put the :Main.main defn into the .hcr file, somehow (filter in the Ext Core output) b)     make TcRnDriver.tcRnExtCore use checkMain to add the defn in when necessary     Well, at least we know what the problem is.  Does this give you enough info to stop your brain melting? Simon   Compiling and running the Main module GHC allows you to determine which module contains the "main" function, and what that function is called, via the -fmain-is flag. The trouble is that the runtime system is fixed, so what symbol should it link to? The current solution is this. Suppose the main function is Foo.run. Then, when compiling module Foo, GHC adds an extra definition:        :Main.main = runIO Foo.run Now the RTS can invoke :Main.main to start the program. (This extra definition is inserted in TcRnDriver.checkMain.) Before starting the program, though, the RTS also initialises the module tree by calling init_:Main, so when compiling the main module (Foo in this case), as well as generating init_Foo as usual, GHC also generates        init_zcMain() { init_Foo; } This extra initialisation code is generated in CodeGen.mkModuleInit.

_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc