Integrating editline with ghc

Judah Jacobson judah.jacobson at
Thu Jan 17 12:22:06 EST 2008

On Jan 17, 2008 6:00 AM, Christian Maeder <Christian.Maeder at> wrote:
> Yitzchak Gale wrote:
> > Christian Maeder wrote:
> >> The extended packages "2" could go under extra libs or hackageDB, while
> >>    "1" remains a boot package for ghc that can link to editline on macs
> >> and readline under linux, but has the same interface and package name!
> >
> > I would hope that ghc will link to editline-ext on all platforms.
> > That gives ghc the functionality it needs without getting
> > into legal trouble with the license. Then those who want the full
> > readline interface can install readline-ext, and those who
> > want the full editline interface can install editline.
> Just to clarify:
> 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).
> The haskell package "editline-ext" is just an add-on that _requires_
> "libedit" (an is only needed for special future developments).
> Also editline-ext should only be used rarely, because some installation
> will still only have "libreadline".
> The new haskell package "readline" will only contain the common
> functionality of libedit and libreadline!
> The new haskell package "readline" should not be renamed in order to
> achieve best backward compatibility in most cases. Renaming it (i.e. to
> "editline") would not change the possibility to either link to libedit
> _or_ libreadline (but would require to change all packages that
> currently use readline)

This sounds fine, except I don't think that we should have a package
editline-ext.  A readline API is either in both libedit and
libreadline (in which case it should be in the readline package), or
it is only in libreadline (in which case it should be in
readline-ext).  The functions in System.Console.Editline are unrelated
to the readline APIs; I think that they should just go in a package
called "editline".


More information about the Libraries mailing list