<div class="gmail_quote">On Tue, Jan 4, 2011 at 5:28 AM, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com">jmdavisProg@gmx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Monday 03 January 2011 22:59:37 Guilherme Vieira wrote:<br>
> Ah, I was under the impression that @trusted was used to force purity.<br>
> Shame.. Sorry I mixed things up.<br>
><br>
> In any case, aren't those rules a bit too rigid? No matter how you look at<br>
> memoize, it should generate pure functions (since it exhibits pure nature,<br>
> are logically pure or whatever you call it). Would it be tough on the<br>
> compiler for it to actually find if a function is pure or not by a more<br>
> detailed analysis of its behavior?<br>
<br>
</div>@safe, @trusted, and @system have nothing to do with purity. If a function is<br>
marked as pure, then it's pure. If it's not, then it's not. End of story. Now,<br>
the concept of "weakly" pure functions was recently added, but all pure<br>
functions are still marked with pure. Strongly pure functions are pure functions<br>
where all of the parameters are immutable or implicitly convertible to immutable<br>
(so, immutable variables and value types). Weakly pure functions are pure<br>
functions whose parameters are not all immutable or implicitly convertible to<br>
immutable. Unlike strongly pure functions, they can alter their arguments.<br>
However, just like strongly pure functions, they cannot access globals or<br>
statics. Strongly pure functions can be optimized such that only one call to<br>
them is made in an expression because their return value will always be the<br>
same, and they cannot alter their parameters. Weakly pure functions cannot be<br>
optimized in that manner, but because they don't alter the global state, they<br>
can be safely called from strongly pure functions without violating the strongly<br>
pure function's purity.<br>
<br>
Pure is not logically pure for essentially the same reasons that const is not<br>
logically const. Making it logical instead of guaranteed eliminates the<br>
guarantees, and the compiler can no longer rely on those guarantees, making them<br>
_far_ less valuable.<br>
<br>
It is true that a memoized function must be logically pure, or you're going to<br>
get errors. However, if you were to force such functions to be pure, it would be<br>
highly limiting. And since memoize _can't_ be pure, it would make recursion with<br>
memoize impossible. True, allowing for memoized functions to be impure makes it<br>
so that the programmer must be more careful, but it's still quite useful - in<br>
fact more useful - that way. And since you _can't_ have memoize be pure anyway,<br>
it's not like you're losing any guarantees from the compiler like if you tried<br>
to make pure logically pure or const logically const.<br>
<font color="#888888"><br>
- Jonathan M Davis<br>
</font></blockquote></div><br>Don't take me too seriously since I'm learning those things on-the-fly here (I'm greedy). The const FAQ (<a href="http://www.digitalmars.com/d/2.0/const-faq.html#logical-const">http://www.digitalmars.com/d/2.0/const-faq.html#logical-const</a>) says D doesn't support logical const because it would break transitivity, and they deemed transitivity to be more important (Walter even thinks it's bad, doesn't he?), so I understand why const in D is not logical const.<div>
<br></div><div>But in the case of memoize, aren't there things that can be done to the language spec to allow it to be pure? Maybe by adding some language construct, I dunno.</div><div><br></div><div>Or by analysis of behavior. Obviously, that wouldn't work for external C functions, but at least memoize would be okay. Also, I'm to guess it would be extremely hard to write a compiler that does this, but I'd just like to confirm.</div>
<div><br></div><div>@Walter: would it be hard/impossible for the compiler to look at memoize and tell it exhibits pure behavior and is, thus, pure?<br clear="all"><br>-- <br>Atenciosamente / Sincerely,<br>Guilherme ("n2liquid") Vieira<br>

</div>