base package (Was: GHC 7.8 release?)
marlowsd at gmail.com
Fri Feb 15 15:45:19 CET 2013
On 15/02/13 08:36, Joachim Breitner wrote:
> Am Donnerstag, den 14.02.2013, 21:41 -0500 schrieb brandon s allbery
>> 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 joachim-breitner.de> 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
Remember that fingerprinting is not hashing. For fingerprinting we need
to have a realistic expectation of no collisions. I don't think FNV is
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.
More information about the Glasgow-haskell-users