base package (Was: GHC 7.8 release?)

Edward A Kmett ekmett at
Fri Feb 15 22:16:50 CET 2013

As a super obvious aside, we could just switch code paths based on platform/environment. That lets you keep the fast code path and have a pure fallback for the javascripters. Just propagate an FFI_AVAILABLE flag into the compilation unit. We're going to have a number of these points which force a tension between generality And speed as we go, and it'd nice to have the ability to gracefully fall back.

On Feb 15, 2013, at 9:45 AM, Simon Marlow <marlowsd at> wrote:

> On 15/02/13 08:36, Joachim Breitner wrote:
>> Hi,
>> Am Donnerstag, den 14.02.2013, 21:41 -0500 schrieb brandon s allbery
>> kf8nh:
>>> On Thursday, February 14, 2013 at 8:14 PM, Johan Tibell wrote:
>>>> On Thu, Feb 14, 2013 at 2:53 PM, Joachim Breitner
>>>> <mail at> wrote:
>>>> I don't think having FFI far down the stack is a problem. There are
>>>> lots of pure data types we'd like in the "pure data" layer (e.g.
>>>> bytestring) that uses FFI. As long as the I/O layer itself
>>>> (System.IO, the I/O manager, etc) doesn't get pulled in there's no
>>>> real problem in depending on the FFI.
>> I think it would be nice, also to other Haskell implementations that
>> might have not have FFI, to separate the really basic stuff from
>> pure-but-impurely-implemented stuff. At least as long as it does not
>> caues trouble.
>> GHC.Fingerprint does not need to be crippled when it is going to use a
>> pure hashing; I quickly added some simple fingerpriting found via
>> Wikipedia that was easier than MD5.
>> The choice is of course not final, maybe something with more bits is
>> desirable.
> Remember that fingerprinting is not hashing.  For fingerprinting we need to have a realistic expectation of no collisions.  I don't think FNV is suitable.
> I'm sure it would be possible to replace the C md5 code with some Haskell.  Performance *is* important here though - Typeable is in the inner loop of certain generic programming libraries, like SYB.
> Cheers,
>    Simon
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at

More information about the Glasgow-haskell-users mailing list