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

From: Wolfgang Lux <wlux_at_uni-muenster.de>
Date: Thu, 02 Mar 2006 09:15:31 +0100

Michael Hanus wrote:

> This is a nice example. The price to pay for this is a limitation
> in the equational reading of function rules.

Huh?

> An important fact
> of Curry is that the different rules defining a function
> have an equational reading, i.e., the order is not important
> so that each rule can be interpreted as an equation under
> which condition a function call can be replaced by another expression.

And this isn't changed by lazy patterns! After all, they are
merely syntactic sugar.

> However, with lazy patterns you can define an operation
>
> not ~True = False
>
> and evaluate (not False) to False. Thus, the little tilde
> (which is, by the way, the blank symbol in LaTeX...) has
> a tremendous influence on the meaning of equations.

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?

Seriously, it is not difficult for a compiler to emit a warning
for dubious code like that example. And a good compiler can be
expected to report a warning about the probably unintended
non-determinism in the example
   f x ~(False:ys) = if x==0 then ys else []
   f x (True:ys) = ys
from one your previous mails.

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

Regards
Wolfgang


_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Do Mär 02 2006 - 09:25:22 CET

This archive was generated by hypermail 2.3.0 : Do Feb 01 2024 - 07:15:07 CET