Well, the documentation says:<div><br></div><div><span class="Apple-style-span" style="font-family: -webkit-sans-serif; font-size: 16px; ">Use <tt style="font-size: 100%; ">{-# NOINLINE foo #-}</tt> as a pragma on any function <tt style="font-size: 100%; ">foo</tt> that calls <tt style="font-size: 100%; "><a href="file:///C:/app/ghc-6.10.1/doc/libraries/base/System-IO-Unsafe.html#v%3AunsafePerformIO" style="color: rgb(0, 0, 224); text-decoration: none; ">unsafePerformIO</a></tt>. If the call is inlined, the I/O may be performed more than once.</span></div>
<div><div><br></div><div>So you claim this does not prevent GHC to inline it anyway? That feels like a bug then, both in the documentation and NOINLINE </div><div><br></div><div><div><div><div class="gmail_quote">On Thu, Apr 16, 2009 at 10:18 AM, Lennart Augustsson <span dir="ltr">&lt;<a href="mailto:lennart@augustsson.net">lennart@augustsson.net</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">There&#39;s no guarantee about unsafePerformIO not being inlined, that&#39;s<br>
just how ghc treats it.<br>
<br>
2009/4/16 Patai Gergely &lt;<a href="mailto:patai_gergely@fastmail.fm">patai_gergely@fastmail.fm</a>&gt;:<br>
<div><div></div><div class="h5">&gt;&gt; On the other hand, breaking referential transparency in the<br>
&gt;&gt; external interface is a very bad idea, in my opinion. Actually,<br>
&gt;&gt; this means that the library user would have to turn certain<br>
&gt;&gt; compiler optimizations off to get the intended behavior.<br>
&gt; However, in practice you can compile Elerea with -O2 without ill<br>
&gt; effects. In fact, that&#39;s what happens if you install it with cabal.<br>
&gt;<br>
&gt;&gt; Just have a look at the Haddock docs of unsafePerformIO.<br>
&gt; Yes, I did that too, and came up with the following checklist:<br>
&gt;<br>
&gt; - the order of side effects doesn&#39;t matter much, since the resulting<br>
&gt; networks are equivalent if we don&#39;t rely on the automatic delay feature<br>
&gt; (applicative optimisations can be different, but still with the same net<br>
&gt; effect)<br>
&gt; - unsafePerformIO is apparently never inlined, i.e. each instance is<br>
&gt; executed once, so sharing works as desired<br>
&gt; - let-floating is no problem, because all instances of unsafePerformIO<br>
&gt; rely on surrounding function arguments<br>
&gt; - CSE is no problem either, it even helps if it&#39;s performed (and it is<br>
&gt; with optimisations turned on), since it results in smaller equivalent<br>
&gt; networks<br>
&gt;<br>
&gt; I think we can expect it to be fairly well-behaving, because the &#39;side<br>
&gt; effect&#39; of Elerea primitives is basically the same as that of pure<br>
&gt; values in general: upon evaluation a value is created in the memory and<br>
&gt; we get a reference to it. We only have an extra constraint for the<br>
&gt; compiler: never duplicate these values. Merging identical ones is okay,<br>
&gt; and in fact desirable. The following code demonstrates this if you<br>
&gt; compile it with and without optimisations:<br>
&gt;<br>
&gt; import Control.Applicative<br>
&gt; import Control.Monad<br>
&gt; import FRP.Elerea<br>
&gt; import System.IO.Unsafe<br>
&gt;<br>
&gt; cint a b = unsafePerformIO (putStrLn &quot;!&quot;) `seq`<br>
&gt;           transfer 0 (\dt x x0 -&gt; x0+x*dt) b<br>
&gt;<br>
&gt; mysig = (latcher 0 (b &gt;@ 0.3) (const (cint a b) &lt;$&gt; cint a b)) +<br>
&gt;        (cint a b) + (cint a b) + a<br>
&gt;    where a = pure 4<br>
&gt;          b = stateful 0 (+)<br>
&gt;<br>
&gt; main = replicateM 10 (superstep mysig 0.1) &gt;&gt;= print<br>
&gt;<br>
&gt; I&#39;d like to see an example where optimisation does make a difference,<br>
&gt; because I&#39;m still unsure about the consequences of &#39;unsafeness&#39;.<br>
&gt;<br>
&gt; Gergely<br>
&gt;<br>
&gt; --<br>
&gt; <a href="http://www.fastmail.fm" target="_blank">http://www.fastmail.fm</a> - Or how I learned to stop worrying and<br>
&gt;                          love email again<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Haskell-Cafe mailing list<br>
&gt; <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
&gt; <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
&gt;<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div></div></div></div>