How much laziness is permitted?

[John Snelson]

Florent Georges wrote:
> John Snelson wrote:
>> As it turns out, try/catch is actually a blocking operation
>> on lazy evaluation. If a lazily evaluated expression inside
>> a try/catch block returns (1, 2, 3) but then raises an
>> error, the implementation effectively needs to
>> "recall" the values (1, 2, 3) and instead return
>> the value of the catch expression. Since most lazy
>> implementations won't have the ability to
>> "recall" values already returned, this means they
>> can't return any values until expression evaluation has
>> terminated - in other words, they need to evaluate eagerly.
> 
>   I have some difficulties understanding the problem.  Could you provide me with a little sample or pseudo code showing such a situation?

try { 1, 2, 3, error() } catch * { "doh!" }

Typically, lazy evaluation will start returning items from expressions 
one by one as they are requested. So lets say I request an item from the 
expression above, and it gives me 1. I do this a couple more times and 
it gives me 2 and 3. Then the next time I request an item, the error() 
function raises an error - and the implementation says "Oh - wait a 
minute! Give me back those answers, I didn't mean them - I meant to 
return 'doh!'.".

In short, if there's a possibility that the try expression could raise 
an error, the try/catch block must fully evaluate it to see if an error 
occurs before it can return any values. So lazy evaluation has been 
"blocked" by the try/catch, and the expression has in practice been 
evaluated eagerly.

John

-- 
John Snelson, Oracle Corporation            http://snelson.org.uk/john
Berkeley DB XML:            http://oracle.com/database/berkeley-db/xml
XQilla:                                  http://xqilla.sourceforge.net