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: Tue, 10 Apr 2007 07:29:17 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1HbAmz-0000wE-S8@wiggum.w3.org>

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





------- Comment #12 from martin@x-hive.com  2007-04-10 07:29 -------
Regarding the first part, I presumed that your functions eventually end up in
Java, or anywhere outside of the scope of your processors optimizations, so it
cannot really tell if a parameter is used or not.

"It cannot be that you discourage the side-effect iteself (e.g. the opening of
a connection)"

I actually do, at least within a functional language. 

Of course, connections need to be opened, so there is state that needs to be
handled. However trying to handle state in a functional language, that is per
definition stateless, is a really bad idea and will lead to many problems, IMHO
(I don't know about the host language part of your implementation, but what
about multi-threading?). I think it's possible to encapsulate such state
managing outside of XQuery, in the host language, and that's what I would do.

"signature extended by unnessary input, and function body extended by tricky
code making the input seem necessary."

The point is that in your example with a function "prepareEnvironment", the
initialized environment is actually the return value of the function, and
following functions obviously take the environment as necessary input, and
depend on it. And they do use the input (the initialized environment) in their
bodies. The difference between imperative languages like Java and functional
languages like XQuery is that XQuery makes this dependency explicit and
visible. And that is A Good Thing (tm), as it has lots of benefits (e.g.
optimizability, code easier to understand, ...).
Received on Tuesday, 10 April 2007 07:29:22 UTC

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