Integrating editline with ghc

[Simon Marlow]

Christian Maeder wrote:
> 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).

I don't think it's necessary to remove (or move) anything from readline at 
all.  That would break clients unnecessarily.

By all means add a new module that exports the lowest-common-denominator API.

>> 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.

But other people really do care about licenses, and it's vitally important 
that each package has a clearly-defined license.

Under my proposal you would be able to do exactly what you want.  The 
difference is that you can't hide the choice between libedit and 
libreadline in a package of its own, unless that package is GPL.

>> 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.

This isn't about GHC, it's about the readline/editline packages!

Cheers,
	Simon