
On 3/8/07, John Meacham
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