# Re: Proposal: Lazy matching for local patterns

From: German Vidal <gvidal_at_dsic.upv.es>
Date: Wed, 24 Oct 2001 17:37:54 +0200 (CEST)

On Wed, 24 Oct 2001, Wolfgang Lux wrote:

> German Vidal wrote
>
> > > > Just one thing:
> > > >
> > > > > The evaluation annotation for the f_i serves the purpose to avoid a
> > > > > possible instantiation of the result of e' by any of the functions f_i,
> > > > > which is IMHO not very useful and -- due to the lazy evaluation of the
> > > > > applications -- in fact unpredictable.
> > > >
> > > > that variables get instantiated by local declarations
> > > > (indeed, this is how it actually works in PAKCS).
> > >
> > > This should happen only in a flexible function (like bar) but not for
> > > rigid functions. E.g. for
> > >
> > > rigidBar n xy
> > > | n == 0 = True
> > > | otherwise = x == y
> > > where (x,y) = xy
> >
> > Right. And strange. It is not so immediate the relation between
> > the evaluation of a local declaration and the evaluation annotation
> > of the function call which uses that local declaration.
> > Moreover, what happens if x and y are used within two different
> > contexts, i.e., one rigid and one flexible?
>
> How should this happen? x and y are connected by the pattern (x,y) and
> thus both must be declared in a single declaration. It is always clear
> (at least it should be :-) whether this declaration occurs in a rigid
> or in a flexible function.

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.

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

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?

Best wishes,
German

---------------------------------------------------------
German Vidal
DSIC - UPV, Camino de Vera s/n, E-46022 Valencia, Spain
gvidal_at_dsic.upv.es
http://www.dsic.upv.es/~gvidal
--------------------------------------------------------

_______________________________________________
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:04 CEST

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