ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?

[Brandon S. Allbery KF8NH]

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 at kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery at ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH