Why does TemplateHaskell cause GHC to load packages? - haskell

I have a trivial Template Haskell program that prints the name of the current module (Main, here):
{-# LANGUAGE TemplateHaskell #-}
module Main
( main
) where
import Language.Haskell.TH
import Language.Haskell.TH.Syntax
modName ∷ String
modName = $(fmap loc_module qLocation »= λmod → return (LitE (StringL mod) ))
main ∷ IO ()
main = putStrLn modName
When I compile this, I get the following Loading messages from ghc:
tsuraan#localhost ~/test/modname $ ghc --make Main
[1 of 1] Compiling Main ( Main.hs, Main.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package containers-0.4.2.1 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Linking Main ...
Why does ghc load all these packages when Template Haskell is enabled? Whenever I build a program that uses Template Haskell, especially one that is built against a lot of packages, my compile warnings are overwhelmed with these superfluous "Loading" messages. It would be nice if I could stop the messages from being printed, or stop the (unnecessary?) module loading from happening at all.

Template Haskell runs at compile time, via a bytecode interpreter (GHCi). Any package dependencies that you have -- at compile time -- will be loaded dynamically into GHC -- at compile time, so that you can execute your splices.
One of your dependencies is the Template Haskell library itself, which in turn depends on most of the core things.

You can prevent the "Loading package" lines from being printed by passing the -v0 flag to GHC. (This also suppresses the "Compiling" and "Linking" lines, but warnings and errors are still shown.)

Related

Dynamic loading under GHCi

I need to be able to load Haskell modules dynamicaally, and evaluate expressions in the context of dynamically-loaded modules.
Hint does it; the problem is, it doesn't work under GHCi, on Windows at least.
cygwin-bash> ghci HintTest.hs
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Ok, modules loaded: Main.
Prelude Main>
Prelude Main> main
[... lots of "Loading package" messages snipped]
GHCi runtime linker: fatal error: I found a duplicate definition for symbol
_debugLn
whilst processing object file
C:\PROGRAM FILES (X86)\HASKELL PLATFORM\2013.2.0.0\lib\ghc-prim-0.3.0.0\HSghc-prim-0.3.0.0.o
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
GHCi cannot safely continue in this situation. Exiting now. Sorry.
I get the same error when using GHC modules directly, as shown in GHC/As a library.
As a compiled program, HintTest runs just fine.
Is there anything that can bee done about this?
I don't ever need to run my program stand-alone; always using GHCi is sufficient. It would also be nice if the program could use GHCi itself as the interpreter and not its own copy of GHC. That is, I'd like to be able to do something like this:
do
context <- loadToGhci "MyModule.hs"
inContext context "MyModule.myFunction 2 5"
and when I return to the REPL, MyModule is magically loaded to it. context is meant to be some kind of monad that carries GHCi state.
Update The same code works on Linux. Perhaps it's a Windows-specific bug in GHC. Can it be worked around?
Update 2
Here's the full log
Prelude Main> main
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package Win32-2.3.0.0 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package old-locale-1.0.0.5 ... linking ... done.
Loading package time-1.4.0.1 ... linking ... done.
Loading package syb-0.4.0 ... linking ... done.
Loading package random-1.0.1.1 ... linking ... done.
Loading package filepath-1.3.0.1 ... linking ... done.
Loading package directory-1.2.0.1 ... linking ... done.
Loading package process-1.1.0.2 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package containers-0.5.0.0 ... linking ... done.
Loading package hpc-0.6.0.0 ... linking ... done.
Loading package hoopl-3.9.0.0 ... linking ... done.
Loading package haskell-src-1.0.1.5 ... linking ... done.
Loading package old-time-1.1.0.1 ... linking ... done.
Loading package Cabal-1.16.0 ... linking ... done.
Loading package binary-0.5.1.1 ... linking ... done.
Loading package bin-package-db-0.0.0.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package ghc-7.6.3 ... linking ... done.
Loading package extensible-exceptions-0.1.1.4 ... linking ... done.
Loading package MonadCatchIO-mtl-0.3.0.5 ... linking ... done.
Loading package ghc-mtl-1.0.1.2 ... linking ... done.
Loading package ghc-paths-0.1.0.9 ... linking ... done.
Loading package utf8-string-0.3.7 ... linking ... done.
Loading package hint-0.3.3.7 ... linking ... done.
GHCi runtime linker: fatal error: I found a duplicate definition for symbol
_debugLn
whilst processing object file
C:\PROGRAM FILES (X86)\HASKELL PLATFORM\2013.2.0.0\lib\ghc-prim-0.3.0.0\HSghc-prim-0.3.0.0.o
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
GHCi cannot safely continue in this situation. Exiting now. Sorry.
You're trying to dynamically load the bytecode interpreter and runtime into the bytecode interpreter and runtime. Whether this works will depend on how the underlying C libraries are linked on your system -- which is very platform dependent.
In particular, C symbols will be duplicated unless special care is taken when linking, when you load the various RTS modules the second time, which will lead to linker errors.

Linking Error Using HsLua on Windows

I am having some issues using HsLua as a library. Lua compiles just fine as a standalone. And this version runs on my Linux box without a problem. Here is the linking error I see.
GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> import Scripting.Lua as Lua
Prelude Lua> l <- Lua.newstate
Loading package hslua-0.3.4 ... linking ... <interactive>: C:\..\AppData\Roaming\cabal\hslua-0.3.4\ghc-7.4.1\HShslua-0.3.4.o: unknown symbol `___strtod'
ghc.exe: unable to load package `hslua-0.3.4'
Prelude Lua>
I did some poking around the libraries and found the call for strtod and I think I may have been close but obviously not close enough.
EDIT
This may or may not help. I'll post the cabal file, I made a couple of changes such as adding the os(windows) portion.
Name: hslua
Version: 0.3.4
...
Extra-source-files: src/*.h
Library
Build-depends: base==4.*
Exposed-modules: Scripting.Lua, Scripting.Lua.ConfigFile
Hs-source-dirs: src
C-sources: src/lapi.c, src/lauxlib.c, src/lbaselib.c, src/lcode.c,
src/ldblib.c, src/ldebug.c, src/ldo.c, src/ldump.c, src/lfunc.c,
src/lgc.c, src/linit.c, src/liolib.c, src/llex.c, src/lmathlib.c,
src/lmem.c, src/loadlib.c, src/lobject.c, src/lopcodes.c,
src/loslib.c, src/lparser.c, src/lstate.c, src/lstring.c,
src/lstrlib.c, src/ltable.c, src/ltablib.c, src/ltm.c,
src/lundump.c, src/lvm.c, src/lzio.c, src/ntrljmp.c
Include-dirs: src
ghc-options: -Wall
extensions: ForeignFunctionInterface
if os(linux)
CC-Options: "-DLUA_USE_LINUX"
if os(darwin)
CC-Options: "-DLUA_USE_MACOSX"
if os(freebsd)
CC-Options: "-DLUA_USE_POSIX"
if os(windows)
CC-Options: "-DLUA_BUILD_AS_DLL"
includes: stdlib.h
I tried a couple of different ways to get the stdlib in the project, I've added it in main headers for the project and I've also specified it in the cabal file. Makes me think that is barking up the wrong tree.
EDIT-2
Well I haven't been able to get this built yet on win32. A couple of other things I tried to do that didn't work for me just in case someone else runs into the same problem.
I linked all of the built object files into a static archive and I got the same error as above. I also tried to use a build DLL and I got a different error but I'm not sure if it were progress forwards or backwards.
C:\..\hslua-0.3.4>ghci liblua.dll -package hslua
GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package hslua-0.3.4 ... linking ... ghc.exe: C:\..\hslua-0.3.4\ghc-7.4.1\HShslua-0.3.4.o: unknown symbol `_lua_close'
ghc.exe: unable to load package `hslua-0.3.4'
Hey I was struggling with exactly the same thing on windows and what worked for me was adding the following to the cabal file
if os(windows)
CC-options: "-D__NO_ISOCEXT"
that makes gcc not use the special __strtod but rather just the normal one.

how do I use an object file created with Cabal?

I have a source file that will only compile with Cabal. It's test code, and in the past (before I complicated my Haskell environment) I would run functions from within ghci.
I know ghci can use object files to load code, but when I try to do so I get the following error. So what am I missing?
[mlitchard#Boris Boris_Test]$ ghci /home/mlitchard/Boris_Test/dist/build/Boris_Test/Boris_Test-tmp/Main.o
GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading object (static) /home/mlitchard/Boris_Test/dist/build/Boris_Test/Boris_Test-tmp/Main.o ... done
final link ... ghc: /home/mlitchard/Boris_Test/dist/build/Boris_Test/Boris_Test-tmp/Main.o: unknown symbol
monadzmcontrolzm0zi3zi1zi3_ControlziMonadziTransziControl_zdfMonadBaseControlIOIO_closure'
linking extra libraries/objects failed
When you specify object files manually, GHCi can't tell what the object file depends on, which it would be able to do with .hs files, because it has access to the import ... lines in that situation.
Therefore, you need to add the object files of all the relevant dependencies manually, in this case by adding -package monad-control, when invoking GHCi.

Using GHCi to load a module without access to its source code

I create a simple module, TestModule.hs, which contains a single exported top-level definition testval = 2. I compile it, creating TestModule.o and TestModule.hi. I delete TestModule.hs. I then load TestModule.o in ghci, like this:
~ λ ghci TestModule.o
GHCi, version 7.0.3.20110517: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading object (static) TestModule.o ... done
final link ... done
Prelude>
As you can see, TestModule isn't in scope and I cannot access testval. Why? How can I accomplish this without access to the source file?
Additional question: how do I accomplish the same thing using the hint package?
Thanks!
You can't interpret something that's already been compiled. If you want to interpret it, you need the source. You can make a package, if you like. Instructions are here.

problem running wxHaskell (Windows)

The page: (http://en.wikibooks.org/wiki/Haskell/GUI) describes that to run wx code, one can install wx and then one must "register wxHaskell with GHC" - but I think the binary installer of wxHaskell (http://wxhaskell.sourceforge.net/download.html) does that automatically?
I installed wx-config, and then wxPack, and wxHaskell. and then did cabal install of wx and wxcore. I am running some wx demos from Leksah, which seem mostly good - but they had some weird errors (I found an alleged solution to that: "wxhaskell-labels-cant-display-full-text"), but I wanted to try some things just from GHCi.
I try to run their simple demos, and the the errors:
D:\csPlangs\Haskell\play>ghci -package wx wxGui1.hs
GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.3.0.2 ... linking ... done.
Loading package stm-2.2.0.1 ... linking ... done.
Loading package bytestring-0.9.1.10 ... linking ... done.
Loading package containers-0.4.0.0 ... linking ... done.
Loading package Win32-2.2.0.1 ... linking ... done.
Loading package filepath-1.2.0.0 ... linking ... done.
Loading package old-locale-1.0.0.2 ... linking ... done.
Loading package old-time-1.0.0.6 ... linking ... done.
Loading package directory-1.1.0.0 ... linking ... done.
Loading package transformers-0.2.2.0 ... linking ... done.
Loading package mtl-2.0.1.0 ... linking ... done.
Loading package parsec-3.1.1 ... linking ... done.
Loading package time-1.2.0.3 ... linking ... done.
Loading package wxdirect-0.12.1.4 ... linking ... done.
Loading package wxcore-0.12.1.7 ... ghc.exe: stdc++: The specified module could
not be found.
<command line>: can't load .so/.DLL for: stdc++ (addDLL: could not load DLL)
And also the [interesting] error:
*Main> q
<interactive>:1:1: Not in scope: `q'
*Main>
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.0.3 for i386-unknown-mingw32):
thread blocked indefinitely in an MVar operation
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
It appears to be a known problem with the combination of wxHaskell, GHCi, and Windows. From http://www.haskell.org/haskellwiki/WxHaskell/Quick_start
On Windows 7, ghci will complain "can't load .so/.DLL for: std c++ ...". But ghc --make Hello.hs; Hello.exe on the command line works well.
So, you can compile your code. You just can't run it through the interpreter.

Resources