Expected time for lazy evaluation with nested functions?
Posted
by
Matt_JD
on Programmers
See other posts from Programmers
or by Matt_JD
Published on 2014-08-24T10:10:10Z
Indexed on
2014/08/24
10:29 UTC
Read the original article
Hit count: 196
functional-programming
|r
A colleague and I are doing a free R course, although I believe this is a more general lazy evaluation issue, and have found a scenario that we have discussed briefly and I'd like to find out the answer from a wider community.
The scenario is as follows (pseudo code):
wrapper => function(thing)
{
print => function()
{
write(thing)
}
}
v = createThing(1, 2, 3)
w = wrapper(v)
v = createThing(4, 5, 6)
w.print()
// Will print 4, 5, 6 thing.
v = create(7, 8, 9)
w.print()
// Will print 4, 5, 6 because "thing" has now been evaluated.
Another similar situation is as follows:
// Using the same function as above
v = createThing(1, 2, 3)
v = wrapper(v)
w.print()
// The wrapper function incestuously includes itself.
Now I understand why this happens but where my colleague and I differ is on what should happen.
My colleague's view is that this is a bug and the evaluation of the passed in argument should be forced at the point it is passed in so that the returned "w" function is fixed.
My view is that I would prefer his option myself, but that I realise that the situation we are encountering is down to lazy evaluation and this is just how it works and is more a quirk than a bug. I am not actually sure of what would be expected, hence the reason I am asking this question. I think that function comments could express what will happen, or leave it to be very lazy, and if the coder using the function wants the argument evaluated then they can force it before passing it in.
So, when working with lazy evaulation, what is the practice for the time to evaluate an argument passed, and stored, inside a function?
© Programmers or respective owner