On 2008 Nov 21, at 9:01, Simon Marlow wrote:
* extract the GHCi UI from the GHC package, put it in the ghc-bin package (maybe we should rename this package to ghc-main or something). This removes the editline and bytestring (for now) dependencies from the GHC package.
* Move to Haskeline for the default build. We have to bring in terminfo and utf8-string as bootlibs. This gives us line-editing on Windows, and removes problematic external C library dependencies.
* Make it possible to compile the ghc-bin package against readline. Upload ghc-bin to Hackage, so people can say cabal install ghc-bin -f readline and get a GHCi built against readline if they want. Oops - except that this would mean that the ghc-main package has a variant license. So maybe we have to have a separate ghc-readline package?
My humble opinion: Dissociate ghc-bin and ghci from ghc; the latter is actually ghci- {haskeline,readline,editline,noediting,...}. (Does cabal have virtual packages yet?) There is a corresponding library issue, though: System.Console.Readline. I'd handle this by having packages which export their own namespaces... but we'd like to have a generic interface too so someone can write a program using any available editing package. So, have the packages also output a module which is by default hidden, and allow the user to select which one is used by unhiding it. (This might lead to wanting additional cabal functionality: "preferred" packages. Or maybe flags already handle that well enough.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH