XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS