Re: Curry report updated

From: Michael Hanus <hanus_at_informatik.rwth-aachen.de>
Date: Tue, 24 Nov 1998 15:36:54 +0100

Dear Wolfgang,

thanks for your remarks which I'd like to comment below.

You wrote:
> After the switch of from flexible boolean functions to flexible constraints functions, shouldn't the constraint functions now be considered as predicates?

Due to your remark, I looked at the uses of the notion "predicate"
in the report and it seems to be inconsistently used due to historical
reasons. Maybe it is better to avoid the term "predicate" at all
(in order to avoid confusing logic programmers since they usually
identify predicates with Boolean functions although they are
not used in such a way) and to use the term "test" for Boolean-valued
functions (since this is the intended use) and provide a hint
to logic programmers that predicates in classical logic programming
correspond to functions of type "Constraint" in Curry.

> In an attempt to simplify the language further, I would suggest to remove the special case for functions with a single boolean guard.

Ok, it's time to remove the "historical ballast".
I see no problem to remove this special case which survived
from history.

> Actually, I think the report is ambiguous about the following definition:
>
> min x y | x <= y = x
> min x y | x >= y = y
>
> It might be either read as two separate rules, in which case it is interpreted as:
>
> min x y | (x <= y) =:= True = x
> min x y | (x >= y) =:= True = y
 Also =:= has been assigned no priority. I suspect it should have infix 4 like ==.
I don't think the report is ambiguous since it is interpreted
in exactly this way, i.e., this results in a non-deterministic
evaluation in contrast to the definition

  min x y | x <= y = x
          | x >= y = y

This is exactly the difference to Haskell: each rule has a meaning
independent of the other rules, whereas in Haskell you have to
consider always the preceding rules. For instance, take the
example

  f x = 0
  f x = 2

which is valid in Haskell although the second "equation" is not
satisfied in the model of the program.

> In the prelude the operator & is given the precendences 0 and 3 and the the operator &> has precedence 0.

Oops, this was a mistake. & should have thje lowest precedence 0 like &>.
And also =:= should have priority 4 like ==.

> I think both should have priority 3, otherwise some of the examples in the prelude won't be parsed correctly.

To which example do you refer? In our implementation, I have assigned
priority 0 to & and everything works well.

> (BTW, shouldn't the report mention a default priority given to the
> operators which have no corresponding infix declaration?)

Right, I'll add it.

> Probably !! should be infixl instead of infixr in the prelude.

Right.

> Now that =:= is a legal infix operator, the list of valid characters for an infixOpId in the lexicon (section C.1, p.44) should be adjusted to include the colon. As a nice side effect the infix declaration
> infixr 5 :
> then would become legal. Even though /\ is no longer predefined I would suggest to include \ in the list of valid operator characters, too.

I agree.

> In the syntax of the report the rule for DataDeclaration (p.46) a meaningless n>0 annotation has survived from some older version of the report.

Thanks for the hint.

> In the rules for type expressions the type Constraint should probably be included among the base types (if they are to be listed in the grammar at all).

In this case I prefer to delete them completely.

Thanks for your remarks,

Michael

P.S.: I collect the changes and waiting for further suggestions
      before I make the next version available.
Received on Di Nov 24 1998 - 15:41:00 CET