Hi, I'm getting errors such as: C:/Documents/Uni/packages/base/GHC/Base.lhs:270:12: Illegal binding of built-in syntax: [] When I try and compile GHC/Base.lhs using the GHC API. Is there some flag I can pass to allow the rebinding of built in syntax? Thanks Neil
On Dec 31, 2007 7:58 PM, Neil Mitchell
Hi,
I'm getting errors such as:
C:/Documents/Uni/packages/base/GHC/Base.lhs:270:12: Illegal binding of built-in syntax: []
When I try and compile GHC/Base.lhs using the GHC API. Is there some flag I can pass to allow the rebinding of built in syntax?
-package-name base should do the thing -- vir http://vir.comtv.ru/
Hi Victor,
-package-name base
should do the thing
Thanks very much, that is the correct flag to allow built in syntax. However, turning that flag on also does other stuff, which breaks new things. Taking the module Prelude.hs, from a darcs checkout of the libraries: C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Ok, modules loaded: Prelude. i.e. you can load the Prelude. However, specifying -package-name base: C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts -package-name base GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help <interactive>:1:22: Failed to load interface for `System.IO': it is not a module in the current program, or in any known package. <interactive>:1:22: Not in scope: `System.IO.stderr' <interactive>:1:22: Not in scope: `System.IO.stdin' : panic! (the 'impossible' happened) (GHC version 6.8.1 for i386-unknown-mingw32): interactiveUI:setBuffering Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This is the same behaviour as loading Prelude without specifying -i. Moving -i to other places still gives the same behaviour. Does package-name base also imply other flags (perhaps -i. ?) which are negatively effecting my particular use. For context, my particular use is to call compileToCore on each file. If the file can be loaded in GHCi, it seems that I can do the compileToCore magic. Thanks Neil
Hi, Neil--
On 1/3/08, Neil Mitchell
Hi Victor,
-package-name base
should do the thing
Thanks very much, that is the correct flag to allow built in syntax. However, turning that flag on also does other stuff, which breaks new things. Taking the module Prelude.hs, from a darcs checkout of the libraries:
C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Ok, modules loaded: Prelude.
i.e. you can load the Prelude. However, specifying -package-name base:
C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts -package-name base GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help
<interactive>:1:22: Failed to load interface for `System.IO': it is not a module in the current program, or in any known package.
<interactive>:1:22: Not in scope: `System.IO.stderr'
<interactive>:1:22: Not in scope: `System.IO.stdin' : panic! (the 'impossible' happened) (GHC version 6.8.1 for i386-unknown-mingw32): interactiveUI:setBuffering
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Yeah, I've seen this before. One thing is that I generally avoid running code that uses the GHC API in GHCi, because I saw some reference somewhere to the fact that data structures can get mixed up that way, and it just seems to lead to madness :-) I've definitely seen the setBuffering panic message before, though haven't filed a bug report since I can't reproduce it reliably. In GHC, though, I can compile base package modules to Core just fine, if I provide the right import flags (-i and -I) so it can find all the dependencies. (If you want to see the complete list of flags I'm using, let me know :-)
This is the same behaviour as loading Prelude without specifying -i. Moving -i to other places still gives the same behaviour. Does package-name base also imply other flags (perhaps -i. ?) which are negatively effecting my particular use.
I don't know, but in GHC (as opposed to GHCi), it all works. I can post some sample code if that would help; let me know. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "More than at any other time in history, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other, to total extinction. Let us pray we have the wisdom to choose correctly."--Woody Allen
| C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts | -package-name base | GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help | | <interactive>:1:22: | Failed to load interface for `System.IO': | it is not a module in the current program, or in any known package. I don't think we'd ever thought of doing this. In particular, I don't think we'd every considered using GHCi in combination with -package-name. Furthermore, I'm not sure we've ever thought what should happen if you use -package-name foo, when compiling with a compiler that already has a package 'foo' (with an identical name) installed. Probably we should check for this case, because it looks likely to lead to confusion. The immediate problem is that GHCi looks for the value "System.IO.stdout" so that it can use it to print things, and it can't find module System.IO, I think because you've overridden the base-package binding. Do you have to use GHCi for this stuff? It's delicate, because GHCi prints things, but you want to compile the very functions it is using to do the printing... Simon
Simon Peyton-Jones wrote:
| C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts | -package-name base | GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help | | <interactive>:1:22: | Failed to load interface for `System.IO': | it is not a module in the current program, or in any known package.
I don't think we'd ever thought of doing this. In particular, I don't think we'd every considered using GHCi in combination with -package-name.
I can't off the top of my head think of a reason why it should fail, unless you use a special -package-name like base, rts, haskell98 or template-haskell.
Furthermore, I'm not sure we've ever thought what should happen if you use -package-name foo, when compiling with a compiler that already has a package 'foo' (with an identical name) installed. Probably we should check for this case, because it looks likely to lead to confusion.
This certainly works, because it must be possible to recompile a package P even though P is installed - it happens when you go back in libraries/ and say 'make', for example. Normally the already-installed P is hidden, because Cabal passes -hide-all-packages to GHC, so things work out fine. Probably GHC ought to filter out P and anything that depends on it from the set of installed packages anyway, to prevent strange things from happening. Cheers, Simon
Hi
I don't think we'd ever thought of doing this. In particular, I don't think we'd every considered using GHCi in combination with -package-name.
The immediate problem is that GHCi looks for the value "System.IO.stdout" so that it can use it to print things, and it can't find module System.IO, I think because you've overridden the base-package binding.
Do you have to use GHCi for this stuff? It's delicate, because GHCi prints things, but you want to compile the very functions it is using to do the printing...
I think in consultation with Tim (many thanks!) I've figured out why things aren't working, and how I can lightly hack around the problem. The first issue seems to be that I'm trying to compile modules from the base library source against preinstalled versions, not versions I've built myself - meaning I lack .hi-boot files. The second issue seems to concern various flags and meanings of flags. What I'm doing is clearly well beyond anything that was ever contemplated, but is working near enough that I can use it to do the next stages. Once I have everything a bit more stabalised, I'll post up my code and my intentions and try and classify the exact issues I am running into. Thanks Neil
participants (5)
-
Neil Mitchell -
Simon Marlow -
Simon Peyton-Jones -
Tim Chevalier -
Victor Nazarov