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

[Ralph Becket]

> From: Peter Schachte [mailto:schachte at cs.mu.OZ.AU]
> Sent: 08 August 2001 13:39
> 
> I like it.
> 
> A few clarifications.  I assume the semantics is identical to the
> if-then-else version?

Pretty much, although I haven't got all the details worked out
in my head yet.

>  What would it mean if I wrote:
> 
> 	...
> 	otherwise f("zip") = throw(...).
> 
> I think you have to forbid anything but unique variables as head
arguments
> in an otherwise clause.  This would ensure that the otherwise clause
would
> always match.

That would be a good 0th-order solution.  I think there's scope to be a
little more general...

> But it could be useful to have non-anonymous head variables
> in cases like:
> 
> 	otherwise f(X) = throw(bad_value(X)).

Yes.  I was also thinking about the possibility of having non-variable
terms in the otherwise clause head.  Imagine something like this:

:- type t ---> foo ; bar ; baz.

:- func f(t, t) = int.

f(foo, foo) = 1.
f(foo, bar) = 2.
f(foo, baz) = 3.

f(bar, foo) = 4.
otherwise
f(bar, _  ) = 5.

otherwise % For any case not covered by the above.
f(_,   _  ) = throw(...).

It's not clear how I'd make this work or whether it's a good idea.
The above requires the compiler to spot that f(bar, _) is more
specific than f(_, _).  What if there was also a clause

otherwise f(_, baz) = 6.

Then there would be no obvious total ordering on the otherwise
clauses.  So allowing more than one looks like a mistake.

> I assume you would also allow:
> 
> 	otherwise f(_) = 4.

Certainly.

> (No reason the otherwise clause should have to throw an exception.)  I
think
> you probably want to limit it to one otherwise clause per function,
and
> require the otherwise clause to be last.

>From the example above, I think the at-most-one restriction may 
be necessary.  I think the requirement that it be the last in a
definition is more to do with good style than anything else.

- Ralph

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------