Integrating editline with ghc

Yitzchak Gale gale at
Thu Jan 17 12:20:30 EST 2008

Christian Maeder wrote:
> ghc will link to "libedit" if it is available on your platform, but the
> Haskell package will still have the name "readline" and give ghc all the
> functionality it needs (without licence problems).
> Only the current readline Haskell package needs "libreadline" and
> supplies more functionality than needed by ghc. This extra-functionality
> should go into a new Haskell package readline-ext (that will only be
> rarely needed).

That is one possible solution for GHC.

The problem is that the readline package currently provides
System.Console.Readline with the full interface to readline.
It has been that way for eons, so we must assume that
there is software out there that uses all of it, even though ghc
only uses part of it. We don't want to break those programs,
and that includes creating a situation where the programs
will no longer compile unless the user installs some new
package with a different name.

So I think the package named "readline" needs to
continue to provide both the interface and the
implementation for full readline. However, if needed,
it can provide some or all of the pieces vacuously by
simply depending on some new packages.

On the other hand, GHC should depend only on a subset
of readline that can optionally be provided by editline
instead. And in fact, editline should be preferred over
readline when available.

There should be a smooth upgrade path to the new system
for all users, both of GHC and the readline, for any
combination of versions installed of any of those things.
Everything should happen automatically as people gradually
upgrade GHC and/or various readline-like packages to new

Can we meet all of those goals?


More information about the Libraries mailing list