How much laziness is permitted?

[John Snelson]

Hi Pavel,

Pavel Minaev wrote:
>   (* module 1 *)
>   declare function m1:gen() {
>       for $x in 1 to 10000 return if ($x lt 10000) then $x else error()
>   }
> 
>   (* module 2 *)
>   declare function m2:trygen() {
>     try { m1:gen() } catch * { () }
>   };
> 
>   (* query *)
>   m2:trygen()[1],
> 
>   let $xs := m2:trygen()
>   for $x in $xs return $x * $x
> 
> 
> Now if the full laziness is still allowed, a legitimate implementation
> can either return 1 when lazy, or () when not. However, I can't wrap
> my head about the second expression. If gen() is implemented lazily
> and returns a generator, then the error will only be triggered on the
> next line while running it. On the other hand, the spec seems to
> require that the error should be caught by the catch block in
> trygen(), since syntactically it appears in gen() when called by
> trygen(). But how can trygen() do this without either doing eager
> evaluation, or relying on some form of re-invokable continuations (to
> backtrack to the proper point of error on exception, and return the
> correct result?

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.

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