yup, i have that! wrapFetch prefetchValue0# (error "this shouldn't get evaluated")
in the test suite! in contrast wrapFetch prefetchValue0# $! (error "this shouldn't get evaluated") does explode shall I add a "should fail" test with the latter? (it doesn't seem worthwhile) On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett <ekm...@gmail.com> wrote: > Maybe test for laziness in the argument by just putting something in that > goes boom when forced, e.g. 'undefined'? > > > On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald < > carter.schonw...@gmail.com> wrote: > >> Hey All, >> as part of trying to get some fixups for how prefetch works into 7.10, >> i'm adding a "prefetchValue" primop that prefetchs the memory location of >> a lifted heap value >> >> namely >> >> several operations of the following form >> >> primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp >> a -> State# s -> State# s >> with strictness = { \ _arity -> mkClosedStrictSig [botDmd, topDmd] >> topRes } >> >> I'd like some feedback on the strictness information design by someone >> who's familiar with how that piece of GHC. the idea being that >> prefetchValue is lazy in its polymorphic argument (it doesn't force it, it >> just does a prefetch on the heap location, which may or may not be >> evaluated). >> >> https://phabricator.haskell.org/D350 >> >> is the code in question. And i *believe* i'm testing for being lazy in >> that argument correctly. >> >> thoughts? >> >> many thanks! >> -Carter >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs