ANNOUNCE: GHC version 6.10.1 - EditLine / terminal
judah.jacobson at gmail.com
Sun Nov 9 12:10:10 EST 2008
On Sun, Nov 9, 2008 at 6:42 AM, Duncan Coutts
<duncan.coutts at worc.ox.ac.uk> wrote:
> On Sun, 2008-11-09 at 01:49 +0000, Ian Lynagh wrote:
>> On Sat, Nov 08, 2008 at 12:33:57PM -0800, Judah Jacobson wrote:
>> > bind "\e[3~" ed-delete-next-char
>> It's a shame this doesn't just work out of the box in an xterm, on
>> Debian at least. Perhaps we should consider switching to haskeline? Do
>> we know anything about how portable and complete that is?
> If we're considering that I think we should consider bringing back
> readline as an option and let the people who have problems with gpl code
> configure in editline support instead.
> Note that haskeline has a lot of dependencies and requires
> TemplateHaskell and many other language extensions.
I'm also somewhat wary of switching to haskeline in ghc-6.10. I think
these issues could be resolved in time for 6.12, though:
1) Completeness: IMHO as the package author, haskeline already has
enough features and cross-platform compatibility to warrant its use by
ghci. (The full feature-list is at http://trac.haskell.org/haskeline/
2) Language extensions: Since ghci is only ever built in stage 2 (and
never by the bootstrapping compiler), the language extensions should
not be an issue. The only exception is TemplateHaskell, as Duncan
mentioned, since it cannot be used by a stage 1 compiler. But TH is
limited to one function in one module and could be easily replaced
either by hard-coding the generated code or by using syb. (Some other
extensions may also no longer be necessary: I haven't checked
3) Dependencies: Outside of ghc's bootlibs, haskeline depends on mtl
and stm (which are extralibs), terminfo (which is only used on POSIX),
- utf8-string should not be needed when unicode text I/O is
implemented for ghc-6.12, as mentioned in
- terminfo is a lightweight binding to a foreign library (ncurses,
really) and could either be added to the bootlibs (my preference) or
folded into the haskeline package.
- stm: I don't see why this couldn't also be a bootlib, although if
necessary I can investigate using MVar-based concurrency instead.
- mtl: haskeline uses MonadTrans and MonadIO from that package, which
ghc reimplements internally. I'm not sure of the right thing to do
More information about the Glasgow-haskell-users