roxen.lists.roxen.general

Subject Author Date
Re: Lazy evaluation of entities is not so lazy? Martin Stjernholm <mast[at]roxen[dot]com> 15-03-2009
"Stephen R. van den Berg" <<srb[at]cuci.nl>> wrote:

> The part of the database actually referenced by the entities in the page
> is pulled in on the fly.
> In the docs it says that class Value types allow lazy evaluation.
> In practice I see that rather consistently, the index operator is called
> first, and directly followed by the evaluation operator which forces me
> to actually query the database immediately.

All the Value class claims is to work for "variable values that are
evaluated when referenced", and it looks like that is what you get.
The other alternative is that the values are calculated when the scope
is created, i.e. even earlier, when you don't know which values
actually are going to be used.

> It would have been better (obviously) if all the index operators of all
> the used entities in the lang scope would have been called first, and
> only *then* the evaluations would be done in one fell swoop.

That's some serious black magic. Might be possible to pull off by
introducing a new rxml type consisting of an array of lazy variable
references and other results, but that could get fairly complicated
and it'd quite likely be slower overall.

Another approach could be to do a scan over the contents before the
actual evaluation to detect the variable references. That otoh isn't
100% accurate (could miss variables that are accessed through pike
code in one way or the other).

Can also note that it's practically impossible to solve in the generic
case: You could have code that looks at foo.a and then depending on
the value decides to look at either foo.b or foo.c. To solve that
you'd have to do a static coverage analysis which initially visits
both branches to figure out that the scope needs to be populated with
all three values. There's of course no support for such a thing on the
pike level. (Besides, at the theoretical end of it you got the Turing
halting problem.)

I don't know your use case of course, but I would probably go for a
solution where the variables are simply listed in the opening tag
instead. One can even consider that a feature: It's akin to how most
"well behaved" programming languages require a variable declaration
before first use.