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