Duncan Coutts wrote:
On Thu, 2008-11-20 at 12:51 +0000, Simon Marlow wrote:
Duncan Coutts wrote:
What I really think is that we should add back optional readline support. People building closed source ghc binaries would not use it but linux distros could enable it and provide a better "out of the box" experience. As I understand it there would be no licencing problems with that approach. One downside I can see is that it gives us an extra configuration to test and maintain. It's hard enough keeping one line-editing binding working, let alone two!
It's true that editline seems to have brought a bunch of headaches with it, though. Perhaps Haskelline is the way to go in the future.
My selfish suggestion is that we maintain the readline configuration and let the people who originally wanted editline support do the work to maintain that configuration. I get the feeling they don't care about if it works well, just that it's got the license they want (which is a perfectly reasonable position).
I propose we do this: * 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? Ok? Cheers, Simon