Integrating editline with ghc
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Tue Jan 22 04:49:21 EST 2008
> 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
>>>> be implemented using libeditline _or_ libreadline. If this
>>>> package is
>>>> call "readline" (with a new version number) most libraries i.e.
>>>> Shellac would not need modifications.
>>> I totally agree. Backwards compatibility for all the programs out
>>> 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
>>> 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?
More information about the Libraries