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.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
