Integrating editline with ghc

[Christian Maeder]

Simon Marlow wrote:
> It would be a bad idea to remove functionality from the readline
> package. It's a binding to the GNU readline library, and as such it does
> a fine job.

I only want to move (not remove).

> For convenience, we would like there to be an API that can be supported
> by both readline and editline.  It would be a bad idea for this to be a
> package, because (as I mentioned earlier on libraries@) that package
> would have a variant license, depending on whether the API-provider was
> readline or editline at build-time (or perhaps in the future link-time
> or run-time).  If you chose between readline and editline, then you have
> to make an explicit choice in your .cabal file - making a package that
> abstracts this choice is not good, unless said package is explicitly GPL'd.

Actually, the license is not (so) important for me. I basically want the
convenience to link against libedit on Macs and against libreadline on
other unix system, because these libs are usually there without further ado.

> So the compatible API could be in a module that is exposed by *both*
> readline and editline, say System.Console.ReadlineCompat.  So your
> source code wouldn't have to change to switch from one to the other,
> just your .cabal file.

Things ghc does not support, users have to do.

Christian