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


Cvs-ghc mailing list

Reply via email to