Integrating editline with ghc

[Manuel M T Chakravarty]

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.

I don't like this either.

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

That's fine if all platforms that by default have readline also have  
editline.  I just checked, Fedora 8 does have both.  How about other  
Linux distros?  What is the situation on Solaris?

Manuel