El 5 de mayo de 2010 08:00, Christian Jaeger chrjae@gmail.com escribió:

...

Are the results of forced delayed computations memoized in Gambit?

Gambit follows R5RS. See the description of force at http://people.csail.mit.edu/jaffer/r5rs_8.html#SEC64

...

If so, is this a recommended method for memoization?

It is the recommended method to write code using call by need, no more, no less.

Call by need means, the evaluation of an expression from a particular runtime context is only being done if the result of the expression is needed, and thanks to the implicit memoization, it is only being done once even if the result (of that same expression from the same context) is needed several times.

It does not however mean that the same promise (and hence memoized result) will be reused if you happen to want the result of the same expression but in a new runtime context, even if the context consists of the same values as earlier.

Ch.

Oh, it's pretty clear in R5RS. I read about this stuff somewhere else where it said that it depended on the implementation.

Thanks,

Álvaro

El 5 de mayo de 2010 15:21, Christian Jaeger chrjae@gmail.com escribió:

In addition to the things mentioned in R5RS that may be implemented differentely between implementations, you also find this:

• whether calling force on a nested promise evaluates only one level

or all levels

Also note that the example implementation given in R5RS is not safe for space in the sense that it doesn't release the thunk of the promise before finishing its evaluation, which leads to similar problems as missing tail-call optimization. I don't know whether any Scheme implementation *is* safe for space in this regard. So the recommendation I gave before is the generally given recommendation, not my personal--I personally generally use my own implementation of delay and force.

Ch.

Hi Christian,

Thanks again for the explanation. Is your implementation sharable or maybe you could give me some pointers?

I'm currently trying out with this other approach (the hashtable), different from force/delay.

http://community.schemewiki.org/?memoization

Bests,

Álvaro

El 5 de mayo de 2010 17:21, Christian Jaeger chrjae@gmail.com escribió:

...

Thanks again for the explanation. Is your implementation sharable or

maybe

...

you could give me some pointers?

https://mercure.iro.umontreal.ca/pipermail/gambit-list/2007-May/001435.html

...

I'm currently trying out with this other approach (the hashtable),

different

...

from force/delay. http://community.schemewiki.org/?memoization

The text on this page is not very bright, in fact it seems to be confusing you. If you need to map a set of values to a computation, then promises don't help you, exactly because they don't provide for any mapping. As I said, Scheme implementations are not required to, and usually do not, detect when a computation (even if wrapped in a delay) has been done previously with the same context values. A new promise is created every time.

Ch.

Yes, what I understood (wrongly, apparently) from the text is that force/delay idioms can be used to memoize the value of a function output given some arguments. If a new promise is created every time it cannot be used directly as a way to put the work of memoization on the compiler (which is what I wanted). I don't look for a call-by-need mechanism, but something to avoid recalculating a procedure every time I pass the same arguments. Anyway I think I have a better picture now.

Best regards,

Álvaro

El 6 de mayo de 2010 00:56, Christian Jaeger chrjae@gmail.com escribió:

I've rewritten the mentioned wiki page to make it hopefully clearer.

Ch.

Yes, it is much clearer now :)

I have now a set of macros and procedures for making memoization simple when needed. It seems to work well.