Re: [xsl] logical operators in *test*

Subject: Re: [xsl] logical operators in *test*
From: David Tolpin <dvd@xxxxxxxxxxxxxx>
Date: Wed, 29 Oct 2003 22:26:24 +0400 (AMT)
> I would say that in fact most programmers learn new languages in exactly 
> that way: work from existing samples and guess at the syntax based on 
> their existing knowledge about other languages. This is especially true 
> for task-specific languages like editor macro languages and "easy" 
> languages like Python and XPath.
> The problem with this approach is that it works just well enough to lead 
> you into deep trouble when you trip over some non-obvious or 
> counter-intuitive language feature, such as "|" being the union operator 
> in XPath expressions.
> Of course, when one finds oneself in that situation, one should actually 
> consult the spec or a good tutorial on the language. RTFM always applies.

I would say that in fact this is a sign of a problem with design
of the language that makes such errors possible.

There is a mainstream tradition;  there are three ways to do
with this fact.

1) one can design a completely different (by its concepts)
language which follows traditions in designation of constructs;
authors of Java went this way and it has proved to be
successful: everything that resembles a C construct works
exactly as in C;

2) one can choose a completely different syntax; a difficult
way, but a good is example is Haskell -- which forces the reader
think differently about things which are different

3) re-use syntatcic constructs of a well-known meaning for
similar but different purposes.  This leads to problems. A nice
example of making this happen is C++ (which reaches its extreme
by allowing (and encouraging) to overload built-in operators.
Another example is XPath.

I realize that it is not due to lack of thought behind the
design; authors of XPath are respectable experts and are
familiar with many different programming languages. It helps
them to think broadly and not  to stay bounds to syntax
traditions of any familiar language.

But the majority of users is not. Too many XPath constructs are
misleading due to their names; of those which are different many
are designed with purity of design in thought, not with clarity
of expression.

Using 'or' where a C programmer expects ||, '|' where a C or pascal
programmer would expect 'or', and completely unexpected (for me) use of
'*' and '.' (instead of any and self,  similar to
preceding::, following:: etc) probably because it somehow reminded
the way file globs are organized, leads to the need to explain
the way .//*[1] is different from a similar but not identical construct.

If XPath (as a part of XSLT) is the first language to learn, then it is
strange, with &lt;= for less-or-equal (in row with
'and' and 'or', would it be more natural to have lt, le, gt, ge,
eq, ne?), but usable, even elegant. If it is not the first language, 
then it is a trap. It is not because people do not read the spec
carefully. It is because a normal brain should not be tried by
switching between concepts at the same time when its owner is
switching between editor's windows.

Another example of uneasy name is generate-id() . What kind of id
does that thing generate? What it returns is not 'id', because
it is not unique in the document. And it does not return, 
it names, because each time it is called for the same node, 
it returns the same value.

Why current() returns a node set, while last() returns an integer? 

David Tolpin

 XSL-List info and archive:

Current Thread