[Haskell-cafe] RFC: Top level mutable state in terms of pure-function initialization?

[Joe Quinn]

This has the same issue as just using a top-level (IORef b). Assume two 
use cases:

let x = enumToIORef 5 in (x, x)
(enumToIORef 5, enumToIORef 5)

It's "obvious" in the first case that you have one ref that is used 
twice, while it is "obvious" in the second case that you have two refs 
containing the same value. But this breaks the rule that (let x = y in f 
x) = (f y), because the left is a single ref while the right is two refs.

There's likely other problems with it too, but this is what stands out 
to me.

On 12/15/2013 6:39 AM, EatsKittens wrote:
> A pure function (enumToIORef :: (Enum a, Defaultable b) => a -> IORef 
> b). This function returns referentially transparently an IORef as a 
> function of its "seed" with the guarantee that the IORef returned is 
> identical if and only if the seed is. This function can be used to 
> implement top level mutable state in a module. The module can 
> specifically create an enumerated type for this and not export it, 
> thereby removing any possibility of another module passing the seed 
> type and conflicting.
>
> The Defaultable class is added in this case to implement only a single 
> method (defaultValue :: Defaultable a => a -> a). This is 
> conceptionally the 'simplest' value of the type, such as the empty 
> list, the number 0, False, the null character &c. The IORef returned 
> by enumToIORef would be initialized before being written to to this 
> specific default value of its type. This approach is chosen because it 
> is impossible to initialize it to user specified value because 
> enumToIORef can be called twice with the same seed but a different 
> initial value.
>
> In the alternative it is also possible to do without the default value 
> and say the IORef returned is the same if and only if the seed and the 
> initial value given are the same. Allowing the function to remain 
> referentially transparent as well. This would probably require for 
> good semantics the underlying type of the IORef to be a member of EQ...?
>
> All this would of course require that newIORef and enumToIORef never 
> produce the same IORef.
>
> Aside its limitations of the type IORef's initialized with this method 
> can carry, I do believe they cover the vast majority of use cases of 
> top level mutable state?
>
> Caveats?
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20131215/33189f8d/attachment.html>