RE: [xml-dev] The Airplane Example (was Re: [xml-dev] StreamingXML)

[Uche Ogbuji <uche.ogbuji@fourthought.com>]

On Wed, 2005-01-05 at 10:22 +0000, Michael Kay wrote:
> > I don't
> > think I can recall having *ever* had a program fail because someone
> > passed a float to a routine that expected an int.  Most errors by most
> > competent programmers (IMO) are of much sterner stuff.
> 
> Someone found a bug in my knight's tour stylesheet three years after it was
> first written. I had never managed to find any input conditions that tested
> the backtracking code, in fact I speculated that the condition could never
> occur. But it did, and the backtracking code was wrong, and the error was
> caught by virtue of the fact that the parameters to a function were being
> passed in the wrong order: f(x,y) instead of f(y,x). 
> 
> (The bug was actually found in the XSLT 2.0 version of the code, to which I
> had added type declarations, which Saxon at that time was only checking
> dynamically. XSLT 1.0 would have carried on to produce incorrect output; the
> current version of Saxon would have detected the error at compile time.)
> 
> So type-checking proved useful here, and static type-checking would have
> been even more useful. But only because the two arguments to the function
> happened to be of different types.

The knight's tour example is very interesting.  Thanks.  I am unclear on
one thing, though.  You say:

"But it did, and the backtracking code was wrong, and the error was
caught by virtue of the fact that the parameters to a function were
being passed in the wrong order: f(x,y) instead of f(y,x). "

So there were two errors there?  The order-of-execution error and the
error in the backtracking bug?  If so, do you consider the backtracking
bug also a type-related error that Saxon/XSLT 2.0 would have caught?

And finally, are you sure the error sources were not really a matter of
function preconditions (which I do support), and were only approximated
by argument typing?

Finally, as I recall the knight's tour XSLT, a lot of the params are
integers.  Would you say the argument transposition error was
fortuitously one where different WXS types *could* be asserted, and that
static typing would have been no help if 2 integer values had been
transposed (i.e. value error)?

I would guess that a precondition may have had more reach (in terms of
safety) in such a case.

Of course most unit testing today is just a matter of pre-conditions,
post-conditions and invariants tested outside the original source code,
because of lack of support for such assertions in most languages (and
because of the inadequancy of mere type checking for ensuring
correctness).


> I think it's very typical of real-life software that exception paths don't
> get adequately tested. In fact, it can be almost impossible to test them. We
> found, for example, that it's impossible to simulate a disc failure
> accurately enough to see how database software will respond to it. The same
> is almost certainly true of aircraft engine failures.

Good point, especially re: my surprise that redundancy didn't save
Ariane, but again I'd say such catastrophic failures are beyond the
reach of most techniques, including static type checking.


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Use CSS to display XML - http://www.ibm.com/developerworks/edu/x-dw-x-xmlcss-i.html
Full XML Indexes with Gnosis - http://www.xml.com/pub/a/2004/12/08/py-xml.html
Be humble, not imperial (in design) - http://www.adtmag.com/article.asp?id=10286
UBL 1.0 - http://www-106.ibm.com/developerworks/xml/library/x-think28.html
Use Universal Feed Parser to tame RSS - http://www.ibm.com/developerworks/xml/library/x-tipufp.html
Default and error handling in XSLT lookup tables - http://www.ibm.com/developerworks/xml/library/x-tiplook.html
A survey of XML standards - http://www-106.ibm.com/developerworks/xml/library/x-stand4/
The State of Python-XML in 2004 - http://www.xml.com/pub/a/2004/10/13/py-xml.html