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
CC:
To: public-qt-comments@w3.org
Message-Id: <E1HaAfR-0000iz-QO@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4441





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

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

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.

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

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