[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Things that make you go Hmmmm!

Subject: Re: [xsl] Things that make you go Hmmmm!
From: Michael Kay <mike@xxxxxxxxxxxx>
Date: Sat, 29 Mar 2014 18:18:40 +0000

> Functional programming is based on functions as first class values. A
> function can appear anywhere that any other atomic value can appear.
> Whether it is on the end of a print statement, as the object of a
> return statement, as a member of a sequence, in a comparison. You
> don't stop and say well I don't see what sense it would make for min
> or gt to compare two functions or a function so I won't allow it.

You're arguing here for a language with very weak typing. To some extent this
was the philosophy of XPath 1.0 - every operator/function is applicable to
every kind of value. It's not entirely true: you couldn't ask for the children
of a boolean, or apply templates to a string, but by and large there were few
dynamic errors. Instead, if you try and add two strings, you would get some
kind of result (like NaN).

If you want to write robust code with a weakly typed language then you need
very thorough test coverage, because very few programming mistakes will be
detected statically. Many of the problems people have with debugging XSLT
arise because too few errors can be detected statically: for example
misspelling an element name in a path expression simply leads to an empty set
result, rather than an error, which is much harder to debug. So while one can
have debates about strong versus weak typing - and indeed, some of the
inconsistencies that we now see are because different people involved in the
design process have had different views on the subject, you certainly can't
dismiss the benefits of strong typing out of hand.

Strong typing is not incompatible with orthogonal language design.
Orthogonality doesn't mean that all operators have to apply to all data
values. (Regarding your example, I'm not sure I have come across a language
that allows one to ask whether one function is greater than another, and if
this operation were offered, I have no idea what it would do.)

The orthogonality rule that "a function can appear anywhere that an atomic
value can appear" is a rule about syntax, not about typing. It doesn't mean
that you can divide one function by another.

Michael Kay

Current Thread