Optimization to better support IORef (Maybe a)

[MathiasBartl]

Hi, I do think that having an IORef (Maybe a) is a pattern that one could make a little module of.
Data.Maybe.IORef
More generaly you have a Type with some unparmeterised constructors, and one constructor with one parameter. (At the moment I don't want to generalise it any further.)
I think Greg posted an link to an concurrent datastructure that removes the indirection and replaces
IORef (a b) with a simple IORef, and represents any parameterless constructor with an constant IORef value. Witch only requires some unsafe coercion.
Now I'd really like to do this, at MULTIPLE points in my Hashtable, and I want to seperate this very technical code for optimisation, from the other technical code for functionality. I also think it would be nice to have it reusable, if there is not already a similar module out there, or GHC does or could do a equivalent optimisation, witch I think is absolutly somethin a compiler could do in principal.
.. to be continued

[rrnewton]

This use of tombstone values was recently mentioned here:

https://ghc.haskell.org/trac/ghc/ticket/9429

I haven't looked at that code -- how does Gregory encapsulate this hack? However, as you pointed out this is purely an (unsafe) optimization, so is something to consider after the basic functionality is rock solid. Let's fix the sequential bugs before the concurrency bugs, and fix the concurrency bugs before introducing new bug categories by abusing GHC ;-).

[MathiasBartl]

Yeah you are absoultly right.
And reading this stuff, absoulty ilustrate that you want to put all this stuff in a seperate modulo,
that looks all nice and harmless from the outside.