Integrating editline with ghc
Christian.Maeder at dfki.de
Mon Jan 21 12:10:55 EST 2008
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.
More information about the Libraries