Avoid Case Analyses

["Costello, Roger L." <costello@mitre.org>]

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

I wonder if Bird's admonishment of case analyses applies to other things, such as specifications?

The XML Schema 1.1 specification is written with extensive use of case analyses. Here's an example from section 3.3.4.3:

5 The appropriate case among the following is true:
5.1 If D has a {value constraint}, and E has neither element nor character [children], and E is not ·nilled· with respect to D , then all of the following are true:
5.1.1 If E's ·governing type definition· is an ·instance-specified type definition·, then D.{value constraint} is a valid default for the ·governing type definition· as defined in Element Default Valid (Immediate) (§3.3.6.2).
5.1.2 The element information item with D.{value constraint}.{lexical form} used as its ·normalized value· is locally ·valid· with respect to the ·governing type definition· as defined by Element Locally Valid (Type) (§3.3.4.4).
5.2 If D has no {value constraint}, or E has either element or character [children], or E is ·nilled· with respect to D, then all of the following are true:
5.2.1 E is locally ·valid· with respect to the ·governing type definition· as defined by Element Locally Valid (Type) (§3.3.4.4).
5.2.2 If D.{value constraint}.{variety} = fixed and E is not ·nilled· with respect to D, then all of the following are true:
5.2.2.1 E has no element information item [children].
5.2.2.2 The appropriate case among the following is true:
5.2.2.2.1 If E's ·governing type definition· is a Complex Type Definition with {content type}.{variety} = mixed , then the ·initial value· of E matches D.{value constraint}.{lexical form}.
5.2.2.2.2 If E's ·governing type definition· is a Simple Type Definition or a Complex Type Definition with {content type}.{variety} = simple, then the ·actual value· of E is equal or identical to D.{value constraint}.{value}.

Conversely, the XPath 3.0 specification is largely written without case analyses.

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?

/Roger