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.
> > > >
> > > > I'm not sure about this change. In principle, one expects
> > > > 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 Wed Oct 24 2001 - 19:35:04 CEST

This archive was generated by hypermail 2.3.0 : Fri Sep 20 2019 - 07:15:05 CEST