Bugs in SampleVar and an API proposal

Bas van Dijk v.dijk.bas at gmail.com
Wed Mar 24 15:50:02 EDT 2010


My proposal[1] of turning the type synonym SampleVar into an abstract
newtype is nearing its deadline (1 day to go).

Please let me hear your +1s or -1s before we can finalize this proposal.



[1] http://hackage.haskell.org/trac/ghc/ticket/3928

On Thu, Mar 18, 2010 at 6:04 PM, Bas van Dijk <v.dijk.bas at gmail.com> wrote:
> Hello,
> I was browsing over the code of Control.Concurrent.SampleVar and
> noticed the same kind of bugs I also discovered yesterday in
> Data.Unique:
> * Throwing an asynchronous exception at the right time can make the
> state of a SampleVar inconsistent which can cause a dead-lock.
> * Numeric expressions are put in a MVar lazily which can cause a space leak.
> The attached patch bundle contains a patch that fixes them both.
> The bundle also contains another patch which changes the API of
> Control.Concurrent.SampleVar. So this patch has to go through the
> library submission procedure.
> I propose making SampleVar an abstract (new)type instead of a type synonym.
> Advantages:
> * Users can not "screw up" the internal state like they can do now.
> * We can define instances for SampleVars without using the
> TypeSynonymInstances language extension. (This is actually the reason
> I bumped into the type synonym nature of SampleVars. I'm making a
> small library that defines some classes and I couldn't make SampleVar
> instances for them)
> Disadvantages:
> * Potentially breaks existing code. However if it breaks your code you
> are probably touching the internals which you shouldn't do anyway.
> Discussion period: 1 week (Because I think this is a no-brainer)
> Note I didn't derive an instance for Typeable for the SampleVar
> newtype. This should be done, but I don't know the proper way
> (manually, LANGUAGE DeriveDataTypeable or
> INSTANCE_TYPEABLE1(SampleVar,sampleVarTc,"SampleVar") ?).
> regards,
> Bas

More information about the Libraries mailing list