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.
> > The problem is the following. Without an evaluation annotation for
> > the accessor functions (and without a global pragma) the default rules
> > apply. E.g., the accessor functions
> >
> > f_1 (x,y) = x
> > f_2 (x,y) = y
> >
> > generated for the expansion of bar and rigidBar are both rigid
> > functions. Thus, "foo z" and "bar 1 z" where z is a free variable
> > will both suspend.
> >
> > Now, if we replace the pairs by the type
> >
> > data StrangePair a = StrangePair Success a
> >
> > the new accessor functions are now
> >
> > f_1 (StrangePair x y) = x
> > f_2 (StrangePair x y) = y
> >
> > where f_1 is now flexible function (because its result type is Success)
> > and f_2 is still rigid. Ignoring for a moment the fact that the Success
> > type is abstract and does not support equality, the result of the
> > application "bar z" would depend on the order in which the accessor
> > functions are evaluated. If f_1 z -- i.e. the x argument of bar' -- is
> > evaluated first, then z is instantiated to a pair (x,x) while if f_2 z
> > -- i.e., y -- is evaluated first, the evaluation suspends. In order to
> avoid such situations, all accessor functions should use the same
> > evaluation mode which is achieved by adding the evaluation annotations
> > to the program.
>
> Nice example.. and nice problem :-)
>
> > The question then is, which mode to use for theaccessor functions?
> > Probably, the best thing is to require that the accessor functions use
> > the same mode as the function in which the pattern declarations occur
> > (this would be compatible with current report). However, this mode
> > depends on whether an evaluation annotation for the function or a
> > global pragma is present and eventually on the type of the function.
>
> This alternatives sound a bit strange for me, because I see
> a relation between the evaluation annotation for the accessor
> functions and the functions which *use* the local bindings,
> rather than between the evaluation annotation for the accessor
> functions and the function where the local declaration appears.
The accessor function's are always *used* by the lifted version of the
function containing the local declaration. And this should IMO use the
same evaluation mode as the unlifted version (though I'm not sure
whether this is stated explicitly in the report).
> Moreover, what would be the problems in having accessor functions
> flexible? Then, if the "context" of the local binging is flexible,
> the computation proceeds, otherwise it suspends. Is it reasonable?
This is not quite correct. Just consider another variant of the bar
example:
bar2 eval rigid
bar2 n xy
| n == 0 = success
| otherwise = x =:= y
where (x,y) = xy
Now the "context" of the local binding is rigid, but the evaluation of
"bar2 1 z" where z is free will not suspend but bind z to the pair
(x,x) if the accessor functions are flexible. It might be
reasonable to expect this behaviour, but I'm still not convinced that
it is.
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 - 11:51:47 CEST