On 2009-01-09 20:45:57 -0500, Jason House <jason.james.ho...@gmail.com> said:
For each function, you'll have to pick
which way you want to go. I don't see what that has to do with D's
future, though, the language allows either.
Somehow, I had the impression that D might use memoization as some kind
of optimization once pure functions are embraced. That was probably a
misunderstanding on my part.
Hum, could the compiler be trusted to add the memoization code to pure
functions so they can stay pure? Something like this:
pure memoize int costlyCalculus(int i, int j)
{
return i + j;
}
being transformed into this by the compiler?
int[TypeTuple!(i, j)] _costlyCalculus_cache;
pure int costlyCalculus(int i, int j)
{
{
int* _found_result = Tuple!(i, j) in
_costlyCalculus_cache;
if (_found_result)
return _found_result;
}
{
int _calculated_result = i + j;
_costlyCalculus_cache[Tuple!(i, j)] =
_calculated_result;
return _calculated_result;
}
}
Surely this way the compiler would be able to bypass purity checks for
accessing the cache while still ensuring that the function has no side
effect and always return the same result for the same arguments. The
downside being that a hash table may not always be the best memoization
technique.
Perhaps then it belongs more in the standard library.
pure int costlyCalculus(int i, int j);
Memoizer!(costlyCalculus) memoizedCostlyCalculus;
where Memoizer is a struct template defining a pure opCall and
containing the cache it can access by casting away purity in a few
places. But it makes it more difficult to add memoization while
overriding a function.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
