Cart
[Home] [By Thread] [By Date] [Recent Entries]
Basically you are expecting that the semantics of a spoken language
is copied 1 to 1 to the syntax of a programming language,
implying that the context should be found where you as a person (with your personal language and cultural background) would expect to find it. That is dangerous, and from the programing language design not robust enough. I think you are overlooking the fact that for a machine you simply need to be more precise. Where do you draw the line? "Jesse James was robbing a bank" "He played the lead role in Jesse James" We all know that in the first sentence I am talking about the person and in the second I am talking about the movie. A computer will never know unless we give it a bunch of logic and some big databases. And my youngest daughter can only imply this since she never heard about the legendary robber, or the movie about him If I had to weight consistency against spoken language semantics, I would value consistency higher and I am happy that "A intersect B" and "A except B" behave the same predictable way I have to make a note that in exercises in my face to face hands-on XSLT courses, students get such concepts as "except" right pretty fast, without examples. For me that means that the design is not too far off What is your next request? Do you want this to work since it is ingrained in us since childhood? <xsl:choose> <xsl:when test="color = 'red'">... <xsl:when test=". = 'blue'">.... in the second when the '.' refers to the color element in the previous branch, simply because in my Flemish language that is what I would expect? Sometimes in language design we need to make decisions on how far we can go with drawing parallels to spoken language expectations and often it is necessary to break the parallel at some point.... and yes, that can lead to discussions like this one. Given that each programmer possibly has a different cultural, socio-cultural and language background, and given that these discussions don't come up too often, I don't think it is bad after all. Maybe an interesting analysis would be to measure the perceived semantic consistency of languages such as Ruby, since that was originated in a cultural context pretty different from the English one Cheers Geert At 11:06 28/11/2012, you wrote: On Wed, Nov 28, 2012 at 9:47 AM, David Carlisle <davidc@xxxxxxxxx> wrote: > On 28/11/2012 07:04, Ihe Onwuka wrote: > >> Well XPath has direct support for union and intersect so for >> completeness we would expect it to support difference. Thats >> reasonable isn't it. So lets go to the part of the specification that >> deals with set theoretic operators and see what it says. >> >> The first hint of trouble is in the URL. >> >> http://www.w3.org/TR/xpath-functions/#union-intersection-except >> >> Lets read on and see why there is support for union and intersection >> and not difference. >> >> op:union Returns the union of the two sequence arguments, >> eliminating >> duplicates. >> op:intersect Returns the intersection of the two sequence arguments, >> eliminating duplicates. >> op:except Returns the difference of the two sequence arguments, >> eliminating duplicates. >> >> So difference is supported except (pun intended) it is called except. >> >> But (sic) the semantic of except that has been ingrained in us since >> childhood is that when you say A except B, B takes it context from A. > > > > > You are not really suggesting that set difference operation (except) should > behave differently with respect to the current node than the union and > intersect operations (or list concatenation are you? >
|
