Duncan Coutts wrote:
On Fri, 2008-11-21 at 14:01 +0000, Simon Marlow wrote:
I propose we do this:
* extract the GHCi UI from the GHC package, put it in the ghc-bin package
(maybe we should rename this package to ghc-main or something). This
removes the editline and bytestring (for now) dependencies from the GHC
package.
This is good independently of the other suggestions.
* Move to Haskeline for the default build. We have to bring in terminfo
and utf8-string as bootlibs. This gives us line-editing on Windows,
and removes problematic external C library dependencies.
I think this is worth trying. It seems like Judah is prepared to put the
work in to make haskeline work on various platforms and to trim the
dependencies.
Eg I'd rather us decide what to do about Unicode input rather than just
end up de-facto standardising the utf8-string package. It seemed like we
had a consensus on what to do for the H98 IO with Unicode. We just need
to get on with it.
Yes - I did some work on this, but didn't finish it. Unfortunately trying
to shoehorn encodings into the IO library isn't pretty, and I became a bit
disillusioned. I could probably still get it working, but I think I was
really hoping that a better architecture for the IO library might emerge,
and so far it didn't :-)
> In addition we need to agree some control over
encoding when using a specific encoding is called for (eg reading a file
that is known to be UTF-16 independent of the locale).
Right, this will certainly be possible when we have System.IO doing
encoding/decoding, we just need to agree on an API.
Oops - except that
this would mean that the ghc-main package has a variant license. So
maybe we have to have a separate ghc-readline package?
A variant license isn't a fundamental technical problem though perhaps
the consensus is that variant licenses are a "bad thing". I'm not sure.
One would have to use OtherLicense and specify what the conditions are
in the license file.
I think it's a good idea to avoid variant licenses, especially in
libraries. We want it to be easy for someone to know whether they're
complying with the licenses for the libraries they depend on, and if those
licenses depend on choices made at the time the library was built, then
it's much harder.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
