[Haskell-cafe] Re: Fast Mutable Variables for the IO and ST monads

[John Meacham]

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⑈