Simon Marlow wrote: > 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.
I only want to move (not remove). > 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. Actually, the license is not (so) important for me. I basically want the convenience to link against libedit on Macs and against libreadline on other unix system, because these libs are usually there without further ado. > 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. Things ghc does not support, users have to do. Christian _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
