We discussed this on IRC the other day but since I have a copy of GHC open I dug through it to refresh my memory. I don't think it would be currently possible with the way things currently are. Someone is free to correct me.
To explain the reasoning, I'll parrot that paragraph and specialize it to this problem: When you build a stage1 compiler, that stage1 compiler is built using symbols and components of the *host* compiler. Let's say I build GHC HEAD stage1, with 7.6.1. So the stage1 compiler is built by the *host* compiler. It links to the host compiler libraries and runtime. Now, let's say we hypothetically compile a plugin for stage1 (somehow.) But now we have a conundrum if we could even load it: that stage1 plugin requires APIs from stage1 itself (for example, maybe the definition of Core changed in HEAD, and your plugin depends on that) but at runtime, when those object files are loaded into stage1, those changed APIs are definitely not there, because stage1 was built with the host, not with itself. So there is a link-time mismatch. So, when stage2 is built, we are sure at runtime it is linked to the same APIs that comprise the stage1 compiler. In this way, stage2 can safely dynamically link packages it has built. This same line of thinking extends to TH and GHCi: if you had a stage1 GHCi, bytecode would be linked into it at runtime, but it would run against the host compiler runtime, not the same runtime the bytecode was compiled for. You could theoretically do some loading-multiple-package-versioning nonsense here, but considering there are plenty of non-versioned symbols (especially C functions,) you're not going to get very far. And the bootstrapping issues aside, there are other direct aspects that are organizational: DynamicLoading (which is used to grab the 'plugin' declaration in a GHC plugin) depends directly on GHCi's Linker module, since it has to link packages into the compiler dynamically anyway. Obviously, Linker.lhs is only built during stage2, provided GHCi is enabled, for all the prior reasons. So DynamicLoading must also depend on #ifdef GHCI in this same way. I don't know how relevant dynamic-by-default here is, but I see how it's going to get you around the first issue, which is the major one. On Mon, Dec 17, 2012 at 5:01 PM, Daniel Vainsencher <daniel.vainsenc...@gmail.com> wrote: > In SimplCore.lhs, addPlugin* is #ifdef GHCI. Is this dependency really > necessary? plugins can be useful independently of the GHCi UI. > > From the wiki [1]: > "Stage 1 does not support interactive execution (GHCi) and Template > Haskell. The reason being that when running byte code we must dynamically > link the packages, and only in stage 2 and later can we guarantee that the > packages we dynamically link are compatible with those that GHC was built > against (because they are the very same packages). " > This does not seem to be a reason to not support plugins and dynamic linking > in general in stage though, or am I missing something? > > Besides finding the dependency in this direction a bit strange, building > stage 2 to debug plugin mechanism problems is a bit slow. > > Thanks, > Daniel Vainsencher > > _______________________________________________ > Cvs-ghc mailing list > Cvs-ghc@haskell.org > http://www.haskell.org/mailman/listinfo/cvs-ghc -- Regards, Austin _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
