Re: [xml-dev] Avoid Case Analyses

[Michael Kay <mike@saxonica.com>]

On 07/10/2012 12:42, Costello, Roger L. wrote:
> Hi Folks,
>
> "Programs that avoid case analyses are clearer and simpler than those that use case analyses."
>
> Professor Richard Bird made that surprising statement in his book, Introduction to Functional Programming.
>
> An extreme example of case analyses is using it to implement an identity function:
>
> color c 	| c == "red"   	= "red"
>               	| c == "green"  	= "green"
>               	| c == "blue"  	= "blue"
>
> It is read:
>
> - In the case the color c is "red" then return "red"
> - In the case the color c is "green" then return "green"
> - In the case the color c is "blue" then return "blue"
>
> The program is more clearly and simply implemented without case analyses:
>
> 	color c   =  c
Well obviously. A program that adds two numbers by enumerating the 
possible cases is going to be a mess. But a program that calculates 
entitlement to disability benefit? It might well be the best way of 
doing it.

Often when the logic is complex one could use a table (decision tables 
were a popular programming metaphor in the 1960s and the idea has a lot 
to be said for it); but tables have their limitations, especially when 
there are more than two dimensions. (See for example 
http://www.w3.org/TR/xslt20/#variable-values, which tries to use a table 
to handle three dimensions).
> Conversely, the XPath 3.0 specification is largely written without case analyses.
It uses case analyses when necessary. See for example section 3.7.2 on 
general comparisons. The editorial style is more inclined to use 
conditionals within prose sentences rather than separate bullet points 
as in XSD, but that's just a typographical difference. And we've had a 
few notorious cases where conditionals in prose have proved ambiguous: 
examples are paragraphs like

If X is Y, then the result is undefined; it is an error if Y is zero

where it's far from clear whether the phrase "it is an error if Y is 
zero" is within the scope of the conditional "if X is Y". The XSD spec 
goes to great pains to avoid the risk of this kind of ambiguity, and on 
the whole it succeeds, but at the expense of readability.
>
> The XML Schema 1.1 specification is considered by most people to be long and cryptic. Perhaps if the authors had avoided case analyses then it would be shorter and simpler.
>
> The XPath 3.0 specification is considered by most people to be short and simple. Perhaps if the authors had used case analyses then it would be longer and more complex.
>
> Thoughts?
>
>
Some editors might be less concerned with shortness and simplicity than 
with precision and absence of ambiguity.

Of course, there are two separate questions: (a) is the spec 
over-complicated, (b) is the spec written as well as it could be? One 
could certainly argue that all these examples from the XSD, XPath, and 
XSLT specifications point to features of the language where the design 
is insufficiently orthogonal, and are symptoms of problems in language 
design rather than technical writing.

Michael Kay
Saxonica