-fbyte-code is ignored in a OPTIONS_GHC pragma

[mnislaih]

When loading a bunch of modules in ghci with -fobject-code, it seems reasonable to be expect that individual GHC_OPTIONS -fbyte-code pragmas will have the effect of loading individual modules via the bytecode backend.

[mnislaih]

As an aside, I am trying to load ghc itself in ghci.

-fobject-code is very handy for me because it seriously speeds up the load times. However, I want to be able to set breakpoints in individual modules

[mnislaih]

For the matter, it looks like -fobject-code in a PRAGMA is being ignored too :(

[simonmar]

This is by design, in fact. GHCi has the restriction that object code cannot be linked to byte-code, so it doesn't make sense to annotate an individual modules with -fbyte-code, because it would force all modules that depend on it to also be loaded with -fbyte-code (and could conflict with other -fobject-code annotations). I think the choice of byte-code/object-code doesn't belong in the source code. But you're right that there ought to be a way to say "I want to load module M as byte code, and whatever depends on it", so I'm changing this to a feature request.

Current workaround is to load the whole of the program with -fobject-code, then switch to -fbyte-code, touch a source file (or remove the object file) and :reload.

[SamB]

I'm beginning to find that restriction rather annoying, too. Why can't object code depend on bytecode? In any case, I would prefer that -fbyte-code in a pragma would cause all dependancies to be byte-compiled, rather than doing nothing.

[simonmar]

I looked into doing this. It's almost possible without major changes, but there's a sticking point: mutually recursive modules.

The core restriction is that pbject code can only link to other object code. This is because byte-code resides in the heap and may move around and be GC'd, so if we allowed object-code to point to byte-code the GC would have to track pointers from object-code to byte-code, which it doesn't (that would be possible). Also object-code itself currently never gets GC'd, because in order to do that the GC would have to track pointers into object-code, which include info pointers. Info pointers are not currently tracked as GC pointers, so this is hard. In short, it's really hard to lift this restriction - we thought about it at the time we designed GHCi, and concluded that it wasn't worth it.

So the tricky bit about allowing -fbyte-code at the module level is that if it occurs within a mutually-recursive group of modules, it has to apply to the whole group. That makes this a bit more than a local change, so I gave up for now.