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 <marlo...@gmail.com> 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 >>>> <m...@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. >> https://github.com/nomeata/packages-base/commit/b7f80066a03fd296950e0cafa2278d43a86f82fc >> 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@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
