<div class="gmail_quote">On Tue, Jan 4, 2011 at 4:48 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:17:52 Guilherme Vieira wrote:<br>
> On Tue, Jan 4, 2011 at 4:05 AM, Andrew Wiley <<a href="mailto:debio264@gmail.com">debio264@gmail.com</a>> wrote:<br>
> > On Mon, Jan 3, 2011 at 10:15 PM, Andrei Alexandrescu <<br>
> ><br>
> > <a href="mailto:SeeWebsiteForEmail@erdani.org">SeeWebsiteForEmail@erdani.org</a>> wrote:<br>
> >> I just added a higher-order function memoize to std.functional which I<br>
> >> think is pretty cool. See the docs here:<br>
> >><br>
> >><br>
> >> <a href="http://d-programming-language.org/cutting-edge/phobos/std_functional.htm" target="_blank">http://d-programming-language.org/cutting-edge/phobos/std_functional.htm</a><br>
> >> l#memoize<br>
> >><br>
> >> I'm also thinking of adding that cutting-edge directory as a place for<br>
> >> storing documentation for commits that are in flux but not officially<br>
> >> released yet.<br>
> ><br>
> > Pretty sweet, but if I'm understanding this correctly, the memoized<br>
> > version of a pure function isn't pure, is it? Is there any way to get<br>
> > that to happen?<br>
><br>
> memoize uses a static variable. Are static variables considered "global" as<br>
> far as pure functions are concerned? If not, then I see no reason for it<br>
> not to be pure, or am I missing something?<br>
<br>
</div>pure functions cannot access mutable globals or static variables. If they could,<br>
they could end up returning a different result with the same parameters because<br>
the global or static variable changed.<br>
<div class="im"><br>
> Additionally, I don't understand this:<br>
><br>
> "Technically the memoized function should be pure because memoize assumes<br>
> it<br>
><br>
> > will always return the same result for a given tuple of arguments.<br>
> > However, memoize does not enforce that because sometimes it is useful to<br>
> > memoize an impure function, too."<br>
><br>
> Wouldn't memoizing an impure function be a.. bug? It would return the same<br>
> cached value when in fact it should have returned something else based on<br>
> external factors. When can that be desirable?<br>
<br>
</div>It's quite easy to have a function which you cannot actually make pure but which<br>
you know to be logically pure. For instance, if a function called a C function,<br>
it can't be pure unless you play some games with function pointers and casting<br>
and the like. So, really, any function which calls a C function can't be pure.<br>
However, it's pretty easy to have a C function which is logically pure. So, your<br>
D function is then logically pure, but it's not actually pure, so pure functions<br>
can't call it. But it would work just fine with memoize. Sure, it's definitely<br>
less safe to use impure functions with memoize, and it could cause bugs, but<br>
that doesn't mean that it shouldn't necessarily be disallowed. It just means<br>
that if the programmer wants to use memoize, they're going to have to be aware<br>
that it could cause bugs if the function in question should actually be<br>
returning a different value on future callls.<br>
<font color="#888888"><br>
- Jonathan M Davis<br>
</font></blockquote></div><br>Ah, I was under the impression that @trusted was used to force purity. Shame.. Sorry I mixed things up.<div><br></div><div>In any case, aren't those rules a bit too rigid? No matter how you look at memoize, it should generate pure functions (since it exhibits pure nature, are logically pure or whatever you call it). Would it be tough on the compiler for it to actually find if a function is pure or not by a more detailed analysis of its behavior?<br clear="all">
<br>-- <br>Atenciosamente / Sincerely,<br>Guilherme ("n2liquid") Vieira<br>
</div>