Re: Strong encapsulation, weak encapsulation, and getSearchTree

From: Wolfgang Lux <wlux_at_uni-muenster.de>
Date: Mon, 14 Jun 2004 19:13:02 +0200

Hi Sergio!

> The VM being developed at PSU, see
>
> http://redstar.cs.pdx.edu/~jimeng/project/
>
> has indeed a clone operation (in the class Term) exactly for the
> purpose you discuss. There is a problem, though. Since the order
> of evaluation is somewhat undetermined, when you clone a term t,
> you do not know how much t has already been evaluated. E.g., in
>
> let x = coin; y = clone x in y `seq` x + y
>
> an interpreter or compiler could evaluate x before cloning it
> and thus y would be a clone of either 0 or 1.

I am aware of the problem of evaluation order. In fact, it was the
reason for using that innocent looking seq application in the example.
It forces y to be evaluated before the addition.

> There is also a dual viewpoint to your proposal. One could throw
> away the call time choice semantics in favor of pure narrowing and
> then introduce a function share. This seems equivalent to your
> proposal and perhaps it is equally reasonable.

You are absolutely right, provided that the sharing introduced by this
function is respected by encapsulated search. Actually, MCC's abstract
machine (at least in the trailing implementation) uses exactly this
approach. An application append Xs Ys is represented by two nodes
   +--------+--------+ +--------+--------+--------+
   | append | -------> | ARGS | -> xs | -> ys |
   +--------+--------+ +--------+--------+--------+
(sorry for the poor ASCII arts, cf. also Fig. 5c) of my WFLP paper).
The right node can be seen as the unshared application append xs ys,
and the left node is just an application of the share function to it.
So the question is, do you prefer to make sharing explicit in source
programs, or breaking of sharing.

Wolfgang


_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Jun 14 2004 - 22:35:12 CEST

This archive was generated by hypermail 2.3.0 : Mi Apr 17 2024 - 07:15:07 CEST