On Wed, Feb 08, 2006 at 11:13:20AM +0000, Simon Marlow wrote: > The problem with doing this is you need a pretty beefy strictness > analyser to be able to tell whether the reference is being used > strictly, this is far beyond what GHC does (I'm impressed that jhc can > do this, but I don't think there's much hope for us doing it in GHC).
What jhc is doing is not quite strictness analysis here (though it does do ghc style strictness analysis at the jhc core phase). this is a sort of 'inverse strictness' where instead of determining whether a function will definitly evaluate a value, it determines when a value will definitly have already been evaluated when passed to a function. so instead of checking whether an IORef will definitly be read and evaluated, it just needs to check if it is always being filled in with already evaluated values. Since ghc (and jhc) core have no way to easily tell the difference between a thunk that we know has already been evaluated and one that might need to be (except in the few cases we can unbox it) this is hard to take advantage of at the core phase but easy in the grin phase where evaluations are explicit. it would be possible to add two types of case statements to core, one which does an 'evaluate then switch' and another that just does a 'switch' assuming the scrutinee has already been evaluated. the second form of case on ghc could just read the closure directly rather than jumping to its code. this would allow ghc to take advantage of this type of 'inverse' strictness analysis. however, it is less powerful when you have separate compilation, it might be useful for local functions or to express other optimizations. like for instance you know the 'switch' version of case will never need to do an update. > Better is for the user to request strict references, and have the > implementation do the unboxing, which is exactly what happens with > IOUArray. Furthermore, it's deterministic: if you ask for an IOUArray > (or IOURef), you're guarnanteed to get unboxing, which is better than > relying on some complex optimisation to work properly. I was thinking just a provided strict reference type, which can be transformed internally into their unboxed forms when one is available, but just act as strict references otherwise. strict references would be generally useful independent of their unboxability and it wouldn't clutter up the API so much. It would be analogous to the (sometimes) automatic unboxing of strict fields in data constructors. such a transformation would need to be carried out always though and can't be considered just an optimization but that shouldn't be a problem as IORefs always have a known monomorphic type (or are never used) John -- John Meacham - ⑆repetae.net⑆john⑈ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe