Integrating editline with ghc
simonmarhaskell at gmail.com
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
More information about the Libraries