W3C home > Mailing lists > Public > public-qt-comments@w3.org > April 2007

[Bug 4441] [XQuery] 2.3.4 Optimization rules unclear?

From: <bugzilla@wiggum.w3.org>
Date: Sat, 07 Apr 2007 13:09:21 +0000
To: public-qt-comments@w3.org
Message-Id: <E1HaAfR-0000iz-QO@wiggum.w3.org>


------- Comment #11 from hrennau@yahoo.de  2007-04-07 13:09 -------
(In reply to comment #9)

You can simply make them depend on each other via input and output data, and
processors will be forced to execute them in order.

The pattern you suggest is in my opinion not reliable, as the evaluation of a
function may simply ignore any argument not needed for determining the function
result. So you have to begin write something strange  *within* the dependent
functions (those which require a precursor). The whole approach amounts to a
heavy load on function design: signature extended by unnessary input, and 
function body extended by tricky code making the input seem necessary. (Further
complication ensues if a dependent function needs the preceding execution of
not one but several functions.) The bottom line is that though the technique of
enforcing sequence by output/input ñhains is fine as an ad hoc approach in a
specific situation, it does not seem to qualify as a reusable pattern to be
employed in a consistent way in a larger collection of library modules. Also
please keep in mind that it is not sufficient if testing proves that the code
works with the present processor version – the code must be safe against future
improvements of optimazation.

I've seen people doing these side-effect calls several times, and I really
think it's not a good idea.

I am not sure I understand would you mean with “doing these side-effect calls”.
It cannot be that you discourage the side-effect iteself (e.g. the opening of a
connection). So maybe you mean discoupling the side-effect from a visible
result to be passed on to a consumer?
Received on Saturday, 7 April 2007 13:09:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:33 UTC