Re: Curry report updated

From: Wolfgang Lux <lux_at_helios.uni-muenster.de>
Date: Tue, 24 Nov 1998 13:41:52 +0000

Hello Michael,

just some other remarks to the report.

After the switch of from flexible boolean functions to flexible constraints functions, shouldn't the constraint functions now be considered as predicates? (This would affect the corresponding statement in section 2 (p.3) and the in the section about types (p.13ff) as well.)

In an attempt to simplify the language further, I would suggest to remove the special case for functions with a single boolean guard. I don't see a reason why these declarations should have another semantics than those with more than one guard (esp. as this semantics differs from the one in Haskell). 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

OTOH, if I first recognize that both rules share the same lhs, it will get interpreted as:

  min x y = if x <= y then x else if x >= y then y else undefined

In the prelude the operator & is given the precendences 0 and 3 and the the operator &> has precedence 0. I think both should have priority 3, otherwise some of the examples in the prelude won't be parsed correctly. Also =:= has been assigned no priority. I suspect it should have infix 4 like ==. (BTW, shouldn't the report mention a default priority given to the operators which have no corresponding infix declaration?) Probably !! should be infixl instead of infixr in the prelude.

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.

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

Regards
Wolfgang
Received on Di Nov 24 1998 - 13:51:00 CET