[
Lists Home |
Date Index |
Thread Index
]
Hi Jeff,
> Lisp provides loops and conditionals as expressions. They are
> incredibly useful, since loops and conditionals can return values
> and be nested inside other expressions. All the C based languages
> (including Java) have conditional expressions, written as (condition
> ? result-if-true : result-if-false).
Quite. As I said, that's precisely the kind of conditional
*expression* that I'd love to see in XPath 2.0. What I don't want is a
conditional *statement*. All the C based languages, including Java
have both: they have a conditional statement:
if (condition1) {
condition1-statements
} else if (condition) {
condition2-statements
} else {
otherwise-statements
}
*and* they have the conditional expression:
condition ? true-expression : false-expression
XSLT already has a conditional statement:
<xsl:choose>
<xsl:when test="condition1">
condition1-statements
</xsl:when>
<xsl:when test="condition2">
condition2-statements
</xsl:when>
<xsl:otherwise>
otherwise-statements
</xsl:otherwise>
</xsl:choose>
It really needs a conditional expression. It doesn't need another
conditional statement.
Similarly, we already have a looping statement in XSLT --
xsl:for-each. Most languages don't have a looping expression as well,
but I recognise that it would be incredibly useful in XPath 2.0.
That's why I said that there should be simple mapping operator, to
handle the 80% of cases where you only need to loop over a single
sequence. I've suggested something like:
sequence-expression -> expression
for example:
(1, 2, 3) -> (. + 1)
would give you (2, 3, 4).
The other 20% would be handled very nicely if XSLT switched focus to
*sequence generation* rather than *result tree generation* and started
viewing sequences and result trees in the same, unified, way as XQuery
does. I've proposed a xsl:item element for this purpose -- see
http://lists.w3.org/Archives/Public/xsl-editors/2002JanMar/0050.html
for details.
> In Lisp, one can write things like:
>
> (let ((x (loop for i from 1 to (length my-list) as item in my-list
> collect (+ i item))) ...)
>
> which creates a new list made by adding the index of the item in the
> original list to the item for each item and binds the local variable
> x to the new list.
Yeah, innit great. But as far as I know, Lisp is a language in its own
right. It doesn't usually get embedded in Java or C. As a matter of
course, you don't have:
int[] x = (loop for i from 1 to (length my-list) as item in my-list
collect (+ i item));
XPath isn't a language in its own right, and I don't think it should
be. If I understand the Lisp above properly, I'd like to see it as:
<xsl:variable name="x"
select="$my-list -> (position() + .)" />
Currently, you have to do it:
<xsl:variable name="x"
select="for $i in 1 to count($my-list),
$item in $my-list[$i]
return ($i + $item)" />
and, because there's no variable-binding within XPath, there are
multiple situations where this syntax does not give you the
functionality that you actually need, and you have to write extension
functions in order to take advantage of XSLT's variable binding
facility.
> Conditionals can be written as (if condition result-if-true
> result-if-false), and use it like this: (some-function (if (> x 0)
> (f x) (g (- x)) ...)
Yes, and I'm not denying that I want to be able to do:
some-function($x > 0 ? f($x) : g(-$x))
> Most Lisp programmers are unhappy to lose conditional and iterative
> expressions when they switch to other languages. In general, the
> statement vs. expression distinction in languages is often more of a
> nuisance than a help, particularly if you are trying to write a
> program to translate one language into another.
I can see that, and that's why in many ways XQuery is the more elegant
language -- it has a beautiful unified syntax because it's taken the
step away from XML-based syntax.
XSLT doesn't have that luxury. When we add statements to XPath,
instead of getting a nice unified language, we get a mess where we
have two ways of doing the same things, one in XPath and one in XSLT.
New users have to learn twice as much, or their tutors decide which
half are the things that they really need to know. Developers will
have to decide on what set of conventions they should use in their
projects. People should not have to make choices about language design
in order to use a language; those choices should have been made during
the design of the language.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
