Re: Lazy Patterns (was: Curry module system and other proposals)

From: Michael Hanus <>
Date: Thu, 02 Mar 2006 15:01:27 +0100

Wolfgang Lux wrote:
> And this isn't changed by lazy patterns! After all, they are
> merely syntactic sugar.

Sorry for being too vague. I mean that function rules without ~
have a direct equational interpretation, i.e., they are not syntactic
sugar for something else. This means that if there is a rule
f p = e, one can always (and only) use this rule to replace
an expression obeying the same form, e.g., an expression
sigma(f p) can be replaced by sigma(e). This property does
no longer hold if p contains ~-patterns because then one
can apply the equation to expressions that do not obey
the given patterns.

> So what?
> not x = False where 1 = 2
> also has a ``tremendous'' influence on the meaning of the equation.
> Should we therefore ban where declarations?

Maybe I misunderstood something but, as far as I can see,
the where declaration has no influence on the applicability
of the equation "not x = False". where-declarations could
have an influence how the right-hand side is evaluated in further
steps but this seems to be consistent since the scope of the
where-declaration is limited to the right-hand side.

> > Thus, I think it is better to make this meaning more explicit
> > in the program code. My argument is less relevant for Haskell
> > since in Haskell many defining equations have no simple
> > equational reading due to the top-down strategy for
> > pattern matching.
> Your argument would equally apply to Haskell, writing code like
> stupidNot ~True = False
> stupidNot False = True
> would be as wrong in Haskell as it is in Curry.

Actually, hugs or ghc does not seem to provide any warning
in this case. And I think this is intended because it is
common practice in Haskell to write equations which have
no direct equational meaning (e.g., default rules). Thus,
if a Haskell compiler warns in this case, many warnings
might be given for standard Haskell programs.



curry mailing list
Received on Do Mär 02 2006 - 15:11:31 CET

This archive was generated by hypermail 2.3.0 : Do Jun 20 2024 - 07:15:08 CEST