ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?

Simon Marlow marlowsd at gmail.com
Mon Nov 24 07:07:34 EST 2008


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



More information about the Glasgow-haskell-users mailing list