<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">This has the same issue as just using a
      top-level (IORef b). Assume two use cases:<br>
      <br>
      let x = enumToIORef 5 in (x, x)<br>
      (enumToIORef 5, enumToIORef 5)<br>
      <br>
      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.<br>
      <br>
      There's likely other problems with it too, but this is what stands
      out to me.<br>
      <br>
      On 12/15/2013 6:39 AM, EatsKittens wrote:<br>
    </div>
    <blockquote
cite="mid:CAFV0NDDJS32m28EJMFB2rV8+AbFOsJqwXzNY2ZzqBkHpfi3rRQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>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.</div>
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div>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...?</div>
        <div><br>
        </div>
        <div>All this would of course require that newIORef and
          enumToIORef never produce the same IORef.</div>
        <div><br>
        </div>
        <div>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?</div>
        <div><br>
        </div>
        <div>Caveats?</div>
        <div><br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Haskell-Cafe mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>