[m-dev.] Adding default clauses to the language.

Peter Schachte schachte at cs.mu.OZ.AU
Thu Aug 9 13:59:02 AEST 2001


On Thu, Aug 09, 2001 at 10:51:59AM +1000, Mark Brown wrote:
> I would oppose this idea; (wearing my purist hat) I am highly suspicious
> of the fact that a single syntactic entity, a clause, does not have any
> well-defined meaning of its own, but depends on the other clauses for
> its interpretation.  In general it would not be possible to verify the
> correctness of an 'otherwise' clause without first looking at other
> clauses for the predicate or function.

Can't argue with you there.  To be clear, though, it's only the otherwise
clause that can't be interpreted separately.  And, when you come right down
to it, you rarely can understand a single clause in isolation.  You have to
understand all the predicates it refers to, also.  Given this, I don't think
it's so bad to ask the reader to look at the other clauses for that
predicate.

> Furthermore (and this is with the purist hat off), you have not
> convinced me that there is any great advantage in allowing default
> clauses.  I like if-then-elses.

I don't.  They're too linear:  first check this, then check that, but only
after checking this.  Worse, you're not allowed to execute the then or else
part until the if part has succeeded.  That's not part of the declarative
semantics, but I believe that's still the operational semantics.  That means
code with an if-then-else won't work in all possible modes.  More
practically, I believe there's still no indexing of if-then-elses (but that
doesn't matter in this case; I'm just griping).

But I guess what attracts me to this idea is that I find it very natural to
think in terms of a catch-all case, like a default label in a C switch.  I
find the status quo of requiring me to write two predicates/functions, or a
huge if-then-else more unpleasant than allowing otherwise clauses.

> The only
> advantage that I can see for using a default clause is that it would
> require fewer levels of indentation, but I think there are better ways
> of achieving this -- namely, introducing additional predicates/functions.

They also allow pattern matching in clause heads, rather than explicit
unifications.

Compare:

	foo(1, 2, 3).
	foo(2, 3, 4).
	foo(3, 4, 5).
	foo(4, 5, 6).
	otherwise foo(_, _, 7).

with:

	foo(A, B, C) :-
		(   A = 1, B = 2 -> C = 3
		;   A = 2, B = 3 -> C = 4
		;   A = 3, B = 4 -> C = 5
		;   A = 4, B = 5 -> C = 6
		;   C = 7
		).

I certainly find the former more readable.

-- 
Peter Schachte                     Brook's Law: Adding manpower to a late
mailto:schachte at cs.mu.OZ.AU        software project makes it later 
http://www.cs.mu.oz.au/~schachte/  
Phone: +61 3 8344 9166             
PGP key available, see web page    
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list