Re: multiway when-catch

----- Original Message ----- 
From: "Kevin Reid" <[email protected]>
To: "Discussion of E and other capability languages" 
<[email protected]>
Sent: Thursday, November 01, 2007 2:49 PM
Subject: Re: [e-lang] multiway when-catch


> On Oct 29, 2007, at 22:36, Rob Withers wrote:
>
>>> Okay, this looks reasonable, though it's more mutable than is good
>>> style. However, whenResolved is not a primitive operation on
>>> references. Look at jsrc/org/erights/e/elib/ref/Ref.java for the
>>> implementation of whenResolved.
>>
>> I see that, now that you point it out.  I am sure there is a good
>> reason for
>> it.  Is it because you want to limit the MirandaMethods defined, and
>> __whenMoreResolved handles the behavior of what you want, so
>> whenResolved
>> and whenBroken are specified in terms of __whenMoreResolved?  Or
>> are there
>> other reasons?
>
> Design principle: Operations should be as simple and un-duplicative
> as possible; having overlapping operations allows misbehaving
> implementations to implement them differently.
>
> Also, since there are many things which must be aware of the entire
> Miranda protocol (forwarders, membranes, other-object-system
> bindings, etc.) it is good to minimize the complexity each must
> reimplement/understand.

I need to take a steady look at the Miranda protocol and adopt it or an 
equivalent functionality.  I have made it Phase 3 of my Plan.

>
> Also, Ref.whenResolved has stronger guarantees than
> __whenMoreResolved which derive exactly from that it is a separate
> implementation. For examples, for any Ref.whenResolved(x, f),
>
>   1. f will not be invoked until x *really is* completely resolved
> (as defined by Ref.isResolved), rather than when it is more-resolved
> or pretending to be resolved.

While using my implementation of CapTP may provide more-resolved situations 
to occur, locally I presently don't have buffering or switching refs, and I 
do implicit shortening with #becomeForward:.  But I should ensure that 
#whenMoreResolved is called with code that ensures #isResolved before 
invoking f, called from #whenResolved:.  #whenResolved: and #isResolved are 
currently implemented on the instance side of my Refs.

>   2. f will be invoked at most once.

Yes.

>   3. f will be passed a reference which is the same as x.

Yes.

Thank you very much for this clear explaination.  If only I could think this 
clearly about these problems,
Rob