ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?)

On Thu, Nov 20, 2008 at 7:16 AM, Ian Lynagh
Although another option would be to make GHCi a separate (GPL) frontend to the (BSD) GHC API. The only downside is that (with static linking) we have another large binary. Another upside is that other GHC API users don't get an editline dependency.
I've actually been experimenting with something similar: darcs get http://code.haskell.org/~judah/ghci-haskeline/ If you have ghc-6.10.1, 'cabal install'ing inside that repo will give you a version of ghci which uses Haskeline as its backend. Basically, I copied 4 modules from the GHC source tree (GhciMonad, InteractiveUI, GhciTags and Main) and modifed them to use Haskeline; the rest of GHC is obtained through the API. Current benefits over the readline/editline versions: - Works on Windows - Tab completion of quoted filenames within Haskell expressions - Tab completion of Unicode identifiers (trac #2058) - Internally, eliminates the need for some GLOBAL_VARs The only real regression I'm aware of is that Haskeline doesn't yet provide a way to "bind" custom key commands as in an inputrc or editrc file. The recent discussion has indicated how important that feature is for some users, so it's next on my TODO list. -Judah

Judah Jacobson wrote:
On Thu, Nov 20, 2008 at 7:16 AM, Ian Lynagh
wrote: Although another option would be to make GHCi a separate (GPL) frontend to the (BSD) GHC API. The only downside is that (with static linking) we have another large binary. Another upside is that other GHC API users don't get an editline dependency.
I've actually been experimenting with something similar:
darcs get http://code.haskell.org/~judah/ghci-haskeline/
If you have ghc-6.10.1, 'cabal install'ing inside that repo will give you a version of ghci which uses Haskeline as its backend.
Basically, I copied 4 modules from the GHC source tree (GhciMonad, InteractiveUI, GhciTags and Main) and modifed them to use Haskeline; the rest of GHC is obtained through the API.
Current benefits over the readline/editline versions: - Works on Windows
I can attest to that. Nice going Judah! $ cabal update $ darcs get http://code.haskell.org/~judah/ghci-haskeline/ $ cd ghci-haskeline $ cabal install and I have a GHCi on Windows that can do completion, history search, and exits when I hit ^D. That's made my day. BTW, your LICENSE file looks like it was copied from the GHC source tree, it still has various references to GHC and the University of Glasgow. Cheers, Simon

| > I've actually been experimenting with something similar: | > | > darcs get http://code.haskell.org/~judah/ghci-haskeline/ .... | > | > Current benefits over the readline/editline versions: | > - Works on Windows | | I can attest to that. Nice going Judah! | | $ cabal update | $ darcs get http://code.haskell.org/~judah/ghci-haskeline/ | $ cd ghci-haskeline | $ cabal install | | and I have a GHCi on Windows that can do completion, history search, and | exits when I hit ^D. That's made my day. If I had £1 for every email I've seen in the last decade about platform-related or license-related problems with readline and now editline, I'd be rich man. Super rich. Could we reduce GHC's surface area by just using haskeline and dumping readline/editline support altogether? Yes that might reduce functionality slightly -- readline/editline are complicated for good reasons. But it's increase functionality in other ways (as Judah says), and by giving us one piece of software that we understand, and can distribute with GHC, it might remove a whole class of problems. Simon

Simon says...
Could we reduce GHC's surface area by just using haskeline and dumping readline/editline support altogether?
I'm in favor of doing this. For portability and consistency, it's better to have just one version that is unencumbered by these license issues, as long as it works on the main platforms (including Macintosh - has that been tested?). If ghc tries to support both readline and editline, along with haskeline, applications written in Haskell will have different behaviours depending on the combination (platform,line-editor). Better just to simplify. John O'Donnell -----Original Message----- From: glasgow-haskell-users-bounces@haskell.org on behalf of Simon Peyton-Jones Sent: Fri 2008-11-21 10:39 To: Simon Marlow; Judah Jacobson Cc: glasgow-haskell-users@haskell.org Subject: RE: ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?) | > I've actually been experimenting with something similar: | > | > darcs get http://code.haskell.org/~judah/ghci-haskeline/ .... | > | > Current benefits over the readline/editline versions: | > - Works on Windows | | I can attest to that. Nice going Judah! | | $ cabal update | $ darcs get http://code.haskell.org/~judah/ghci-haskeline/ | $ cd ghci-haskeline | $ cabal install | | and I have a GHCi on Windows that can do completion, history search, and | exits when I hit ^D. That's made my day. If I had £1 for every email I've seen in the last decade about platform-related or license-related problems with readline and now editline, I'd be rich man. Super rich. Could we reduce GHC's surface area by just using haskeline and dumping readline/editline support altogether? Yes that might reduce functionality slightly -- readline/editline are complicated for good reasons. But it's increase functionality in other ways (as Judah says), and by giving us one piece of software that we understand, and can distribute with GHC, it might remove a whole class of problems. Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Hello,
2008/11/21 John O'Donnell
Simon says...
Could we reduce GHC's surface area by just using haskeline and dumping readline/editline support altogether?
I'm in favor of doing this. For portability and consistency, it's better to have just one version that is unencumbered by these license issues, as long as it works on the main platforms (including Macintosh - has that been tested?).
It works very well on my Mac. Both tab completion of quoted filenames in Haskell expressions and of unicode identifiers works well. (It doesn't complete non-latin file names, but I can live with that.) I've also noticed that with haskeline one can type in ghci non-latin characters, as was the case before, with readline, but not anymore with editline. Hope it helps C.Chryssochoidis
If ghc tries to support both readline and editline, along with haskeline, applications written in Haskell will have different behaviours depending on the combination (platform,line-editor). Better just to simplify.
John O'Donnell
-----Original Message----- From: glasgow-haskell-users-bounces@haskell.org on behalf of Simon Peyton-Jones Sent: Fri 2008-11-21 10:39 To: Simon Marlow; Judah Jacobson Cc: glasgow-haskell-users@haskell.org Subject: RE: ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?)
| > I've actually been experimenting with something similar: | > | > darcs get http://code.haskell.org/~judah/ghci-haskeline/ .... | > | > Current benefits over the readline/editline versions: | > - Works on Windows | | I can attest to that. Nice going Judah! | | $ cabal update | $ darcs get http://code.haskell.org/~judah/ghci-haskeline/ | $ cd ghci-haskeline | $ cabal install | | and I have a GHCi on Windows that can do completion, history search, and | exits when I hit ^D. That's made my day.
If I had £1 for every email I've seen in the last decade about platform-related or license-related problems with readline and now editline, I'd be rich man. Super rich.
Could we reduce GHC's surface area by just using haskeline and dumping readline/editline support altogether? Yes that might reduce functionality slightly -- readline/editline are complicated for good reasons. But it's increase functionality in other ways (as Judah says), and by giving us one piece of software that we understand, and can distribute with GHC, it might remove a whole class of problems.
Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Fri, Nov 21, 2008 at 2:27 AM, Simon Marlow
Judah Jacobson wrote:
On Thu, Nov 20, 2008 at 7:16 AM, Ian Lynagh
wrote: Although another option would be to make GHCi a separate (GPL) frontend to the (BSD) GHC API. The only downside is that (with static linking) we have another large binary. Another upside is that other GHC API users don't get an editline dependency.
I've actually been experimenting with something similar:
darcs get http://code.haskell.org/~judah/ghci-haskeline/
If you have ghc-6.10.1, 'cabal install'ing inside that repo will give you a version of ghci which uses Haskeline as its backend.
Basically, I copied 4 modules from the GHC source tree (GhciMonad, InteractiveUI, GhciTags and Main) and modifed them to use Haskeline; the rest of GHC is obtained through the API.
BTW, your LICENSE file looks like it was copied from the GHC source tree, it still has various references to GHC and the University of Glasgow.
The vast majority of code in that project is copied directly from the GHC source tree, and any changes I've made are intended to be merged back into GHC (or a ghci subproject); so I thought it easiest just to keep the code under the same license and copyright. Is there a better way to do this? -Judah
participants (5)
-
Christos Chryssochoidis
-
John O'Donnell
-
Judah Jacobson
-
Simon Marlow
-
Simon Peyton-Jones