Integrating editline with ghc

Simon Marlow simonmarhaskell at
Mon Jan 21 10:54:31 EST 2008

Christian Maeder wrote:

> Depending on what the ghc team and the library maintainers decide,
> either "readline" has to be changed to "readline-compat" in *.cabal or
> (worse) we get packages Shellac-readline and Shellac-editline or (more
> worse) Shellac-readline stays as is and I have to fiddle with editline
> or readline on Macs myself (like now).

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.

In a similar vein, we should have an editline package that provides a 
binding to libedit.

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.

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.


More information about the Libraries mailing list