Integrating editline with ghc

[Manuel M T Chakravarty]

Don Stewart:
> chak:
>> 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.
>
> I agree, it makes no sense to hide/obscure readline. Just depend on a
> different package.
>
> So as for the regex-compat lib, we can live happily with a readline- 
> compat
> that gives a compatible interface to readline, via other means.

Yes, readline-compat seems like the right package name for this.

Manuel