Subject: Re: [SWIPL] Type error vs. silent failure

From: "Richard A. O'Keefe" <[email-masked]>
Date: Mon, 29 Oct 2001 11:21:48 +1300 (NZDT)

Paulo Moura <[email-masked]> wrote:
	Always doing argument checking for library predicates is probably 
	overkill for many applications.

I disagree.  There is certainly a practical question about HOW MUCH
checking is a good idea.  For example, if you have a library package
that is supposed to implement binary search trees, it would be a bad
idea to check the tree argument in full every time, because that would
spoil the logarithmetic cost that is the whole reason for using such trees.

In the absence of a static type system, error reports at run time are
important.  A reasonable level of checking is one of the most useful
services a library implementor can provide for the library users.

When you are determined to do a workmanlike job of error reporting,
it's amazing what little crannies you can find to wedge a useful amount
of error detection into without much overhead.  Certainly, whenever you
already have an if->then;else, there's a fair chance you can squeze an
error check in.

	I have been playing around with the idea of defining two sets of
	library objects:  one for debugging or critical applications
	containing error-checking code for every predicate and another
	version with that safe belt removed for applications that do not
	need/want error-checking.  The two versions of the objects will
	share the same name.  The programmer or the application will
	choose the version to load (possibly with some compiler flag).
	
This has been compared to wearing a lifejacket when the boat is on the
slip-way, but taking it off when the boat is in the water.  It is a
proven Bad Idea.

The machine on my desk is 150MHz, and it's only a few years old.
1.5GHz machines are now in the shops for less money.
Removing error checking code in the name of speed is a perverse
way of wasting development time.