GHC Api

[Simon Marlow]

On 02/01/14 07:06, Simon Peyton-Jones wrote:
> Simon and othere
>
> Happy new year!
>
> When debugging Trac #8628 I wrote the following:
>
> main
>
>    = do  [libdir] <- getArgs
>
>          ok <- runGhc (Just libdir) $ do
>
>            dflags <- getSessionDynFlags   -- (1)
>
>            setSessionDynFlags dflags
>
>            liftIO (setUnsafeGlobalDynFlags dflags)  -- (2)
>
>            setContext [IIDecl (simpleImportDecl pRELUDE_NAME)]  -- (3)
>
>            runDecls "data X = Y Int"
>
>            runStmt “print True”              -- (4)
>
>          return ()
>
> There are several odd things here
>
> 1.Why do I have to do this “getSessionDynFlags/setSessionDynFlags”
> thing.  Seems bizarre.  I just copied it from some other tests in
> ghc-api/.  Is it necessary?  If not, can we remove it from all tests?

It's a sensible question given the naming of the functions.  The API is 
definitely clunky here, but there is a purpose to these calls. 
setSessionDynFlags loads the package database and does the necessary 
processing to make packages available.  We don't do that automatically, 
because the client might want to add their own package flags to the 
DynFlags between the calls to getSessionDynFlags and setSessionDynFlags. 
Incidentally you can find out some of this stuff from the Haddock docs, 
e.g. look at the docs for setSessionDynFlags.

> 2.Initially I didn’t have that setUnsafeGlobalDynFlags call.  But then I
> got
>
> T8628.exe: T8628.exe: panic! (the 'impossible' happened)
>
>    (GHC version 7.7.20131228 for i386-unknown-mingw32):
>
>       v_unsafeGlobalDynFlags: not initialised
>
> which is a particularly unhelpful message.  It arose because I was using
> a GHC built with assertions on, and a warnPprTrace triggered.  Since
> this could happen to anyone, would it make sense to make this part of
> runGhc and setSessionDynFlags?

I'm not all that familiar with the unsafeGlobalDynFlags stuff (that's 
Ian's invention), but from looking at the code it looks like you 
wouldn't need to call this if you were calling parseDynamicFlags.  It 
should be safe to call parseDynamicFlags with an empty set of flags to 
parse.

> 3.Initially I didn’t have that setContext call, and got a complaint that
> “Int is not in scope”.  I was expecting the Prelude to be implicitly in
> scope.  But I’m not sure where to fix that.  Possibly part of the setup
> in runGhc?

I think it's sensible to require a call to setContext to bring the 
Prelude into scope.  The client might want a different context, and 
setContext isn't free, so we probably don't want to initialise a default 
context.

> 4.The runStmt should print something somewhere, but it doesn’t.  Why not?

I've no idea!  It does look like it should print something.

Cheers,
	Simon

> What do you think?
>
> Simon
>