# Re: Proposal: Lazy matching for local patterns

From: Wolfgang Lux <lux_at_wi.uni-muenster.de>
Date: Wed, 24 Oct 2001 17:57:46 +0200

German Vidal wrote

> Ok, I'll try to clarify my position. Consider the following program:
>
> foo n xy
> | n==0 = rigidF x y
> | n==1 = flexF x y
> where (x,y) = xy
>
> rigidF eval rigid
> rigidF 0 y = y*y
>
> flexF eval flex
> flexF 1 1 = 1
>
> This is what I meant with "the context where x and y appear", functions
> rigidF and flexF (instead of the function where the local declaration
> appears, i.e., foo).
>
> Here, if foo is rigid, I would expect that both calls "foo 0 z"
> and "foo 1 z" get a suspension, since this would be the behavior
> with the following (equivalent? at least for this example?)
> definition of foo:
>
> foo eval rigid
> foo n (x,y)
> | n==0 = rigidF x y
> | n==1 = flexF x y
>
> Thus, the accessor functions should be rigid.
>
> However, if foo is flexible, the situation is not so clear. Here,
> I would expect that the call "foo 0 z" gets a suspension, but
> "foo 1 z" evaluates to 1 with the binding { z -> (1,1) }, since
> this would be the behavior with the following (equivalent?)
> definition of foo:
>
> foo eval flex
> foo n (x,y)
> | n==0 = rigidF x y
> | n==1 = flexF x y
>
> Thus the accessor functions should be flexible.

But now the mode of the accessor functions depends on the mode of foo
but not on the "context". This behaviour, which seems reasonable to ask
for, is just the current semantics of the report. I would not object to
using it.

> Wolfang has given several examples where having accessor functions
> flexible could be problematic (and I agree with him). However, if
> I'm not wrong, having them always rigid we have that

To be precise, the problem is not having flexible accessor functions
but having both rigid *and* flexible accessor functions used in the
same function. It will not cause any problems -- at least none which I
can think of at the moment -- to have flexible accessor functions used
in the expansion of one function and rigid functions for another
function.

> foo eval flex
> foo (x,y) = x+y
>
> and
>
> foo eval flex
> foo n = let (x,y) = n in x+y
>
> are different functions... Is this reasonable?

IMHO, yes. In general both definitions give different functions. Just
replace x+y by const x (const y 0) and you will see a difference
between both function, namely for foo undefined.

Regards
Wolfgang

```--
Wolfgang Lux				  Phone: +49-251-83-38263
Institut fuer Wirtschaftinformatik	    FAX: +49-251-83-38259
Universitaet Muenster		      Email: wlux_at_uni-muenster.de
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
```
Received on Mi Okt 24 2001 - 19:35:05 CEST

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