Providing a smooth default user experience

Simon Hengel sol at
Fri Nov 9 23:16:41 CET 2012

Hi Duncan,

> > That is interesting.  I'd be interested in how exactly that works.  Is
> > there a place where I can read about it?  Or if not, can you point me to
> > the related commits?
> For the changes to ghci see the ghc git repo. Look for stuff related
> to .ghci file handling. That was the main extension needed, so we could
> specify a .ghci file on the command line.

Thanks a lot for the pointers.

I looked at [1] (specifically at mkDotGhci), but as far as I can tell
this does not work anymore.

Here is what I tried:

    ghci> :def! foo (\_ -> return "23")
    ghci> :foo
    ghci> :def! reload (\_ -> return "23")
    ghci> :reload
    Ok, modules loaded: none.

It seems that builtins always take precedence over user defined
commands.  I tried this with GHC 7.2.2, GHC 7.4.2 and GHC 7.6.1.

It works with GHC 7.0.4.  But even here the code has issues, because it
does an :undef so that it can call the original :reload.  But after that
our custom :reload is gone.  So it works, but only once.  This is easily
fixed, e.g. the following works with GHC 7.0.4:

    ghci> :def! __reload__ (\_ -> return ":!echo 'do-cabal-specific-stuff'\n:undef reload\n:reload\n:def reload (\\_ -> return \":__reload__\")")
    ghci> :def! reload     (\_ -> return ":__reload__")
    ghci> :reload 
    Ok, modules loaded: none.
    ghci> :reload 
    Ok, modules loaded: none.

I think if we want to redefine :reload we need the :def semantics we had
in GHC 7.0.4.  Should I open a GHC ticket?



More information about the cabal-devel mailing list