Hi Raphael,
> - The new operation ByNeedFuture combines the three concepts together.
> The by-need computation is protected by a read-only, and exceptions
> are catched and returned as failed values. This was suggested by
> Denys. It is equivalent to
>
> fun {ByNeedFuture P}
> !!{ByNeed fun {$} try {P} catch E then {Value.failed E} end end}
> end
I looked at the actual code in share/lib/base/Base.oz, and I found:
ByNeedFuture = proc {$ P X}
R={Boot_Value.newReadOnly}
in
thread
{WaitNeeded R}
try Y=!!{P} in
% necessary if R has no demanding suspension
{Boot_Value.makeNeeded Y}
{Boot_Value.bindReadOnly R Y}
catch E then
{Boot_Value.bindReadOnly R {FailedValue E}}
end
end
X=R
end
Isn't this unnecessarily complicated? Why the second read-only? Could
you comment this design; that would be very helpful.
> - The former implementation of futures will be removed from Mozart.
> Maintaining both implementations introduces unnecessary complexity,
> and therefore degrades readability of the code. This decision is
> supported by the fact that no performance degradation has been
> observed with the new implementation (see below).
Well... yes and no. We certainly don't want to keep the old futures
as they are. However the performance argument is missing the actual
point that I discussed before and which is about resources
(e.g. memory).
The plan that I wish to pursue is as I described previously: to
eventually replace ByNeedFuture with a resource-optimized
representation (i.e. one that delays allocation of resources until
needed). The wonderful thing about the new foundation is that such an
optimization becomes very straightforward and semantically clean: what
is a ByNeedFuture? It is simply a ReadOnly variable with the
additional twist that, when this variable becomes needed, a
computation is started (as described by the current implementation in
Oz).
Of course, that's my itch, and I perfectly understand if you don't
feel like scratching it :-) I can do that myself.
> - Read-only variables (the ones you get with !!X) have been
> reimplemented, in a way very similar to former futures.
but more efficiently/economically using the bidirectional propagator
trick.
Cheers,
-- Dr. Denys Duchier Équipe Calligramme LORIA, Nancy, FRANCE - Please send submissions to hackers@mozart-oz.org and administriva mail to hackers-request@mozart-oz.org. The Mozart Oz web site is at http://www.mozart-oz.org/.