[Haskell-cafe] idea for avoiding temporaries

Josef Svenningsson josef.svenningsson at gmail.com
Fri Mar 9 05:11:38 EST 2007


On 3/8/07, John Meacham <john at repetae.net> wrote:
> it seems we can almost do this now without adding any new API calls,
> just have 'thawArray' and 'freezeArray' perform the check, and behave
> like 'unsafeThawArray' or 'unsafeFreezeArray' when they are the only
> reference.
>
> The compiler may even be able to statically replace some
> calls to thawArray or freezeArray with the unsafe versions with an
> extension of the rules syntax
>
> {-# RULES forall a | unique a . freezeArray a = unsafeFreezeArray a #-}
>
> this syntax actually came up in a previous discussion about wanting to
> fire rules only when the argument is a constant literal (though, you don't
> care about the particular constant value it is)
>
> I imagine infering the uniqueness of values shouldn't be that hard as a
> form of it is already done for avoiding thunk-updates.
>
You have to be careful here. Uniqueness typing is not the same as
usage analysis but the two are confusingly similar. Imagine a function
which takes, say, an array as it's argument. If it says that the array
is unique, then there must only be a single reference to that array as
the function probably updates it destructively. Compare this to the
situation where we say that the array is only used once in the
function. The array may have other references to it in this case, the
function doesn't care.
This boils down to the fact that the usage analysis propagates
information to the point where a value is created; should the thunk be
updateable or not? Whereas with uniqueness analysis we propagate
information to the point where it is used: is it OK to destructively
update the value instead of copying it?

I'm also not sure that inferring uniqueness types in the compiler
would be the way to go. I think David wants to be certain that his
arrays are not copied. Having to inspect the output of the compiler is
not the nicest way to do this. Some mechanism which enables the
programmer to tell the compiler what his intent is (such as the
uniqueness type system a la Clean) would be much preferable.

Of course, that doesn't mean that your idea is useless. It could
still, and probably would be, a very valuable optimization in the
compiler. I just don't think that it will help David with his
particular problem.

Cheers,

Josef


More information about the Haskell-Cafe mailing list