[xquery-talk] XQuery error codes and rewriting

[Jeff Dexter]

True, but in those environments you typically have controls (albeit
non-standard ones) to ratchet down the level of optimization to bypass
these scenarios (and get the results you expect). The HotSpot Java VM is
filled with options to prevent it from optimizing code into bugs.

While I imagine a lot of XQuery implementations will have such controls
as well, it would be nice if either those controls were standard or
there was some standard mechanism for a user to find out what's going on
in a query when the results are not what they expect. 

Something akin to fn:trace (but for optimizations) would likely be quite
helpful to users trying to understand what's happening to their query.
The ability to selectively or globally disable these optimizations may
also be helpful (especially in distinguishing bugs vs. features) but
that's likely too difficult to apply generally to XQuery
implementations.

Jeff.

-----Original Message-----
From: talk-bounces at xquery.com [mailto:talk-bounces at xquery.com] On Behalf
Of Michael Rys
Sent: Thursday, February 02, 2006 1:40 PM
To: Daniela Florescu; Michael Kay
Cc: Peter Coppens; talk at xquery.com; David Carlisle; John Snelson
Subject: RE: [xquery-talk] XQuery error codes and rewriting
Importance: Low

Dana is correct. Except for that the latest optimizing hardware
processors actually do stuff that make C and Java programs result in
wrong results according to the language semantics....

Michael

> -----Original Message-----
> From: talk-bounces at xquery.com [mailto:talk-bounces at xquery.com] On
Behalf
> Of Daniela Florescu
> Sent: Thursday, February 02, 2006 1:21 PM
> To: Michael Kay
> Cc: talk at xquery.com; 'Peter Coppens'; 'David Carlisle'; 'John Snelson'
> Subject: Re: [xquery-talk] XQuery error codes and rewriting
> 
> Michael,
> 
> this has nothing to do with SQL and databases per se. It has
> something to do with do optimizations.
> 
> The kind of optimizations and rewritings a database does for
> its declarative languages (and that make this entire industry so
> useful) are inherently in tension with a 100% specified semantics
> of such languages.
> 
> Imperative programming languages like Java and C have a
> very clear semantics, tightly controlled, but as a result
>   they are limited in terms of the rewritings and optimization
> they can do while being strict about the semantics.
> 
> In XQuery we defined the semantics in such a way that it leaves
> the door open for some optimizations that we knew in advance
> that will be useful (like shortcircuiting quantifiers).
> 
> But there are hundreds of other rewritings that people will invent
> for XQuery over time, that we didn't anticipate when we wrote the
> semantics.
> 
> Such implementations will not be conformant at 100%. But that's fine.
> If they give users an order of magnitude better performance they'll
> buy it despite that.
> 
> The tension is between determinist semantics and optimization,
> and I am not aware of a good answer for this tension.
> 
> Best regards,
> Dana
> 
> 
> 
> On Feb 2, 2006, at 12:39 PM, Michael Kay wrote:
> 
> >> Was it never considered to remove that paragraph altogether?
> >>
> >> I am sure that in that case some implementations will never be able
to
> >> fully comply, but at least to me that seems preferable over what
you
> >> have now.
> >
> > There are one or two people on the working group who incline to this
> > kind of
> > position, that when it comes to the complicated edge cases, it
doesn't
> > matter what we say because implementors will do their own thing
> > anyway. This
> > kind of thinking tends to come, I think, from people from the
database
> > community where the expectations that products will conform 100% to
> > SQL or
> > any other standard are historically quite low. On the whole, though,
> > the
> > level of conformance of products in the XML space is much better,
and
> > if you
> > look at the core specs such as XML itself and XSLT, even the most
minor
> > infringements of the spec give a product a lot of flak. For many of
us
> > therefore, it's very important that the spec spells out exactly what
is
> > allowed and what isn't, even if this sometimes means being more
> > liberal than
> > one would like for 100% interoperability.
> >
> > Michael Kay
> > http://www.saxonica.com/
> >
> >
> > _______________________________________________
> > talk at xquery.com
> > http://xquery.com/mailman/listinfo/talk
> 
> _______________________________________________
> talk at xquery.com
> http://xquery.com/mailman/listinfo/talk

_______________________________________________
talk at xquery.com
http://xquery.com/mailman/listinfo/talk