Re: Language change proposal

From: Michael Hanus <hanus_at_medoc.informatik.rwth-aachen.de>
Date: Tue, 7 Jan 1997 15:18:28 +0100

Dear Sergio,

Thanks for your proposal about the relaxation of
Curry's restrictions w.r.t. extra variables.
I am very much in favor of your proposal,
but I think we have to clarify some points.

You wrote:
> There is a fundamental difference between the operational
> semantics of Curry and Haskell. In Haskell, if a term pattern
> matches the lhs of a rule, a committment is made to permanently
> disqualify pattern matching the term with any other rule lhs.
> Thus a guard has the primary role of delaying or preventing this
> committment until more information than that of a pattern is
> known. In other words, guards may very well fail, but
> where-clauses should never fail.

I think this is not entirely true. I tried the following definition

f x | x==0 = 0
f x | x==1 = 1

in Haskell (Hugs):

Hugs session for:
/usr/local/lib/hugs/1.3/lib/Prelude.hs
Type :? for help
? :l patterntest
Reading script file "patterntest":
                   
Hugs session for:
/usr/local/lib/hugs/1.3/lib/Prelude.hs
patterntest
? f 1
1

So, the failing of a guard means that pattern matching has failed
and thus the next rule is applied.

>From my understanding, the basic difference between guards and
where-clauses is the difference between evaluation and definition:
guards are expressions which must be evaluated to the truth value,
while where-clauses introduces local (function) declarations.
Thus, in Haskell one can only use the strict equality (==)
in guards and the (directed) non-strict equality (=) in where-clauses.
The paper by Suzuki, Middeldorp, and Ida covers only one aspect
of where-clauses: the instantiation of extra variables by
matching a function call against a pattern. For this kind
of applications your proposed extension is quite useful.
However, the other aspect of where-clauses, namely the
definition of local functions, is not covered by this extension.
Thus, I think that the final language need both: extra variables
in guards for constraint solving applications (where strict
equality or other predicates are used), and where-clauses
which can be seen as local let-declarations.

One final point: I think that extra variables occurring in
a right-hand side are also useful even if they are not
instantiated by simple pattern matching (see the example

last xs | append _ [x] == xs = x

which I showed in a previous email). Such a use of
extra variables is useful if the value of the
extra variable is computed by some general constraint solving
and it is ensured that only one solution exists (for instance,
by selecting the best solution). Unfortunately, there are
no simple syntactic criteria to ensure the confluence
for such applications. A possible solution is to check
for the requirements you proposed and provide a warning
to the user if a clause does not satisfy these requirements
(but the compiler accepts also the more general cases
which cause no implementation problems in a functional
logic language).

Best regards,

Michael
Received on Di Jan 07 1997 - 15:32:13 CET