[xquery-talk] XQuery error codes and rewriting

[Michael Rys]

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