[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Avoid Case Analyses

• From: "Costello, Roger L." <costello@mitre.org>
• To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
• Date: Sun, 7 Oct 2012 13:34:35 +0000

Hi Folks,

I just had an epiphany:

    Case analyses is essentially using
    examples to define a function (or
     in the case of a specification to 
     specify a behavior).

A friend of mine frequently reminds me that examples should never be used to define or specify, they should only be used to illustrate.

This epiphany has given me a deeper insight into why Professor Bird admonishes cases analyses.

Thoughts?

/Roger
-----Original Message-----
From: Costello, Roger L. 
Sent: Sunday, October 07, 2012 7:43 AM
To: xml-dev@lists.xml.org
Subject: Avoid Case Analyses

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

• Follow-Ups:
  • Re: RE: Avoid Case Analyses
    • From: John Cowan <cowan@mercury.ccil.org>
  • Re: RE: Avoid Case Analyses
    • From: "Simon St.Laurent" <simonstl@simonstl.com>

• References:
  • Avoid Case Analyses
    • From: "Costello, Roger L." <costello@mitre.org>