ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?

Judah Jacobson judah.jacobson at
Sun Nov 9 12:10:10 EST 2008

On Sun, Nov 9, 2008 at 6:42 AM, Duncan Coutts
<duncan.coutts at> 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

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),
and utf8-string.

- 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 mailing list