[xquery-talk] Everything is a sequence ...so ....

[Ihe Onwuka]

..are there any drawbacks to always using the general comparison form

thisThing = ('thatThing')

rather than

thisThing eq 'thatThing'

even when you know that you are dealing with a singleton sequence.

I am guessing this may be an implementation dependent issue.

[Liam R E Quin]

Post by Ihe Onwuka
..are there any drawbacks to always using the general comparison form
thisThing = ('thatThing')
rather than
thisThing eq 'thatThing'
even when you know that you are dealing with a singleton sequence.

I find I can catch a lot of errors by using eq.

I can conceive of an implementation in which eq is faster but I doubt by
very much, you'd have to measure. I've often been quite surprised at
relative speeds of things though.

[Michael Kay]

The eq operator is easier to optimize because the type conversions it does are much simpler (in particular, exploiting indexes is more difficult). However, because 90% of the time people use "=", optimizers are likely to work hard at it even though it's intrinsically more difficult.

But getting into the habit of using "eq" is something I would recommend because of the better diagnostics when you get things wrong.

Michael Kay
Saxonica

Post by Ihe Onwuka
..are there any drawbacks to always using the general comparison form
thisThing = ('thatThing')
rather than
thisThing eq 'thatThing'
even when you know that you are dealing with a singleton sequence.
I am guessing this may be an implementation dependent issue.
_______________________________________________
http://x-query.com/mailman/listinfo/talk

[Andrew Welch]

Post by Michael Kay
The eq operator is easier to optimize because the type conversions it does are much simpler (in particular, exploiting indexes is more difficult). However, because 90% of the time people use "=", optimizers are likely to work hard at it even though it's intrinsically more difficult.
But getting into the habit of using "eq" is something I would recommend because of the better diagnostics when you get things wrong.

The problem I have with eq is the potential for this:

<xsl:variable name="foo" select="() eq ()" as="xs:boolean"/>

(or maybe it's with xs:boolean)

There is a thread here:

http://markmail.org/thread/htioi45g53pswcv2

[Ihe Onwuka]

Post by Michael Kay
The eq operator is easier to optimize because the type conversions it does are much simpler (in particular, exploiting indexes is more difficult). However, because 90% of the time people use "=", optimizers are likely to work hard at it even though it's intrinsically more difficult.
But getting into the habit of using "eq" is something I would recommend because of the better diagnostics when you get things wrong.

I try, but you can stare an awful long time at

someString eq ('stringA','stringB')

and not realise what is wrong.

Mentally we are not attuned to distinguishing eq from =.

I wonder whether it would have been better if eq were = and = were
=>, but then I guess you'd have to worry about how to deal with the
other comparison operators as well.

[Liam R E Quin]

Post by Ihe Onwuka
you can stare an awful long time at
someString eq ('stringA','stringB')
and not realise what is wrong.

I don't know, the message
Single item expected, ("stringA", "strinB") found.
seems a good hint...

But I don't think of eq and = as being the same.

Post by Ihe Onwuka
I wonder whether it would have been better if eq were = and = were
=>, but then I guess you'd have to worry about how to deal with the
other comparison operators as well.

We had to be compatible with XPath 1 at least to that extent.

After all, if we were not compatible the Web browsers would never move
to XSLT 2... (hmm).

[David Lee]

If I were writing the language over I would never have '=' do set intersections or whatever the math term for
"some item on the left side set is also equal to some item on the right side set"

Maybe something like operators "contains" or "has" or "oneof" or something ... but "=" ?
That took me a long long long LONG time to get used to.

of course now its way fun and I cant imagine it another way :)

This one blows me too ...

( <foo/> eq <foo a="bar"/> ) => TRUE !!!!

Yes I know why ... now ... but that took me about a decade to notice.




-----Original Message-----
From: talk-***@x-query.com [mailto:talk-***@x-query.com] On Behalf Of Liam R E Quin
Sent: Saturday, January 25, 2014 4:59 AM
To: ***@gmail.com
Cc: ***@x-query.com
Subject: Re: [xquery-talk] Everything is a sequence ...so ....

Post by Ihe Onwuka
you can stare an awful long time at
someString eq ('stringA','stringB')
and not realise what is wrong.

I don't know, the message
Single item expected, ("stringA", "strinB") found.
seems a good hint...

But I don't think of eq and = as being the same.

Post by Ihe Onwuka
I wonder whether it would have been better if eq were = and = were
=>, but then I guess you'd have to worry about how to deal with the
other comparison operators as well.

We had to be compatible with XPath 1 at least to that extent.

After all, if we were not compatible the Web browsers would never move to XSLT 2... (hmm).


--
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

_______________________________________________
***@x-query.com
http://x-query.com/mailman/listinfo/talk

[Liam R E Quin]

Post by David Lee
If I were writing the language over I would never have '=' do set
intersections or whatever the math term for
"some item on the left side set is also equal to some item on the right side set"

"implicit existential quantification".

It's done because of multiple elements with the same name,
and feels very natural in XPath, but not so natural in XQuery.

Liam