Add --with-libedit flag to the readline package

[judah]

It would be useful for the readline package to support compiling against the libedit library (which provides a subset of the readline APIs):

• libedit is available by default on OS X.
• since libedit is BSD-licensed, there are no problems statically linking ghc with it. (This may be useful on Windows.)

I propose adding a --with-libedit flag to the readline autoconf script. Without that flag, the package will behave exactly as before, refusing to link against libedit. With that flag, the following behavior occurs:

• GNUreadline.framework (OS X - only) is ignored, if present
• We try to link with -lreadline, and don't fail if readline is actually libedit.
• If it is libedit, we #ifdef out all of the functions not supported by libedit. (these are generally low-level APIs not needed by most applications, including ghci.) Otherwise, if we're linking against GNU readline, we support all the available APIs.

Suggested deadline: Jan. 23, 2008.

[thorkilnaur]

I would suggest creating an entirely new Haskell library (which rightly should be called "edit", but a better name should probably be found) for such Haskell bindings to the BSD edit library on Mac OS X. Apple's idea of pretending that "edit" is "readline" has caused quite some significant confusion over the years. I would not expect a Haskell readline library which is perhaps really the BSD edit library to be any less confusing.

For example, I may wish to work specifically with both the BSD edit library and the GNU readline library though some Haskell binding, to compare them. Such a case would be difficult to handle with a Haskell readline library which is either BSD edit or GNU readline.

I am aware that this loses the potential advantage that BSD edit functionality will be present for free, rather than no line editing capabilities, in some cases, such as GHCi. But I am convinced that this advantage will be outweighed heavily by the ensuing work needed to deal with these confusing scenarios.

Any helpful magic, similar to your suggestions, for automatically selecting between BSD edit and GNU readline must then be implemented separately, perhaps as a library in itself.

Best regards Thorkil

[judah]

The consensus on the libraries list is that (as Thorkil says) it would be much better make a new package, editline, which would provide the readline APIs as a separate module.