Hi, Some of the nofib suite are messed up by Yhc/nhc because of the monomorphism restriction. Take imaginary/bernouilli as an example: powers = [2..] : map (zipWith (*) (head powers)) powers Hugs and GHC both see powers :: [[Integer]] and a CAF. Yhc (and nhc) both see powers :: (Enum a, Num a) => [[a]] and no CAF. This completely destroys the performance in Yhc/nhc. Since this is not so much a performance aspect but a compiler bug, based on a feature whose future in Haskell' is as yet unclear, perhaps it would be wise to patch nofib to include an explicit type signature where this matters. I am happy to send in a patch (or just apply it) - but I have no idea who "maintains" the suite. I've CC'd those people who make substantial use of the nofib suite. Thanks Neil
By all means apply a patch, I think. Simon | -----Original Message----- | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Neil Mitchell | Sent: 03 December 2007 17:34 | To: Haskell Cafe | Cc: Simon Marlow; Malcolm Wallace; Duncan Coutts | Subject: [Haskell-cafe] Nofib modifications | | Hi, | | Some of the nofib suite are messed up by Yhc/nhc because of the | monomorphism restriction. Take imaginary/bernouilli as an example: | | powers = [2..] : map (zipWith (*) (head powers)) powers | | Hugs and GHC both see powers :: [[Integer]] and a CAF. | | Yhc (and nhc) both see powers :: (Enum a, Num a) => [[a]] and no CAF. | | This completely destroys the performance in Yhc/nhc. Since this is not | so much a performance aspect but a compiler bug, based on a feature | whose future in Haskell' is as yet unclear, perhaps it would be wise | to patch nofib to include an explicit type signature where this | matters. I am happy to send in a patch (or just apply it) - but I have | no idea who "maintains" the suite. I've CC'd those people who make | substantial use of the nofib suite. | | Thanks | | Neil | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe
I'd do something like #if defined(__nhc98__) || defined(YHC) #define NO_MONOMORPHISM_RESTRICTION #endif #ifdef NO_MONOMORPHISM_RESTRICTION powers :: [[Integer]] #endif just to make it quite clear what's going on. (good comments would do just as well). Cheers, Simon Simon Peyton-Jones wrote:
By all means apply a patch, I think.
Simon
| -----Original Message----- | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Neil Mitchell | Sent: 03 December 2007 17:34 | To: Haskell Cafe | Cc: Simon Marlow; Malcolm Wallace; Duncan Coutts | Subject: [Haskell-cafe] Nofib modifications | | Hi, | | Some of the nofib suite are messed up by Yhc/nhc because of the | monomorphism restriction. Take imaginary/bernouilli as an example: | | powers = [2..] : map (zipWith (*) (head powers)) powers | | Hugs and GHC both see powers :: [[Integer]] and a CAF. | | Yhc (and nhc) both see powers :: (Enum a, Num a) => [[a]] and no CAF. | | This completely destroys the performance in Yhc/nhc. Since this is not | so much a performance aspect but a compiler bug, based on a feature | whose future in Haskell' is as yet unclear, perhaps it would be wise | to patch nofib to include an explicit type signature where this | matters. I am happy to send in a patch (or just apply it) - but I have | no idea who "maintains" the suite. I've CC'd those people who make | substantial use of the nofib suite. | | Thanks | | Neil | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe
Hi
I'd do something like
#if defined(__nhc98__) || defined(YHC) #define NO_MONOMORPHISM_RESTRICTION #endif
#ifdef NO_MONOMORPHISM_RESTRICTION powers :: [[Integer]] #endif
just to make it quite clear what's going on. (good comments would do just as well).
I'd rather avoid CPP, as Hugs doesn't have CPP by default (certainly on Windows), so it would make it a little harder to run with Hugs. I am happy to write comments such as: -- only required for compilers that fail to correctly implement the monomorphism restriction Thanks Neil
participants (3)
-
Neil Mitchell -
Simon Marlow -
Simon Peyton-Jones