Integrating editline with ghc

[Simon Marlow]

Manuel M T Chakravarty wrote:
> Malcolm Wallace:
>> Christian Maeder <Christian.Maeder at dfki.de> wrote:
>>
>>> 1. a _new_ readline package that only contains the interface that can
>>> be implemented using libeditline _or_ libreadline. If this package is
>>> call "readline" (with a new version number) most libraries i.e. like
>>> Shellac would not need modifications.
>>
>> I totally agree.  Backwards compatibility for all the programs out there
>> that already use the readline package (but really don't care whether it
>> is actually readline or editline) is vital.  I would hate to see all
>> client code forced to use CPP macros and cabal magic to select the right
>> package and module imports.  We can avoid such a retrograde step by
>> explicitly making 'readline' the backend-agnostic package, which
>> re-exports functionality from either the real readline or editline,
>> depending on which is available.
> 
> I don't think we should touch the existing readline package.  It's a 
> binding to readline and whether everybody likes its license or not 
> doesn't matter.  Some people just want to use readline, and they should 
> be able to continue to do this by importing the library called 
> System.Console.Readline.
> 
> In addition System.Console.Editline should be a binding to editline.  
> (Again if somebody want editline and nothing else, that's what they 
> import.)
> 
> Finally, we'd like a module (let's call it EditReadline) whose interface 
> coincides with the readline emulation layer of editline (ie, 
> <editline/readline.h>).  This module should use editline where it is 
> available and otherwise readline (if that is available).  We can argue 
> about where in the hierarchy EditReadline should be located (and whether 
> we want to call it EditReadline or something else).  Following Judah's 
> proposal, it could be System.Console.Editline.Readline (essentially 
> following the C header structure), but it could alternatively be 
> System.Console.EditReadline (or something else).

I think it would be a bad idea to provide EditReadline as described.  The 
reason being that this would be a package with a variant license: its 
license is conditional on how it is built, which makes it that much harder 
for clients to understand what licensing restrictions apply, and to license 
themselves appropriately.  (the alternative is to make EditReadline GPL, 
but that defeats the purpose).

I don't even think we've considered variant licenses in Cabal before, and 
my inclination would be to disallow or at least vigorously discourage it.

So I suggest we just keep readline as it is, and packages that want to use 
editline can switch at their discretion, using 
System.Console.Editline.Readline to make porting easier.  In GHC I imagine 
we'll just switch to using editline.

Cheers,
	Simon