[e-lang] Proposal: deprecate "rcvr" in favor of "ref"

[Marc Stiegler]

Since we can't come to a quick closure on this...

I have personally always thought it was a mistake to try to capture the 
subtlety of "possibly remote, you better only make sends, don't do 
calls" in the guard name. My real preference has always been, name the 
guard "far", and use documentation to explain that it might not be far, 
even though only an idiot would make an immediate call without first 
coercing it through the near guard.

The truth is, the naive interpretation of "far" or "remote" leads the 
programmer to correct behavior, whereas everything else (including rcvr) 
leads to puzzlement. If we lead the programmer to correct behavior, he 
wins. If we leave him puzzled, he loses.

What was the goal of giving these things names anyway, if not to lure 
the poor soul into correct behavior? Sure, leading to correct 
understanding as well as correct behavior is swell, but we have now 
spent six years using a term that mainly encourages the programmer to 
either go back to the documentation, or to get tired of being sent off 
to the documentation and go back to using C++.

--marcs

Dean Tribble wrote:
> Your examples of "What we'd ideally like to say," makes me want a 
> clarification:   For example, "possibly eventual" permits of manually 
> testing whether the reference is near, and then just using it as near.  
> Since I think that's generally a bad style, I was assuming that the 
> guard should represent the programmer declaration that the reference 
> should be only treated eventually ( i.e., with "send"), even if it's 
> not.  This would typically be used for references that might be remote, 
> but might be used within a vat e.g., for observers that should not be 
> invoked synchronously.  Which semantics does/should this guard specify?
> 
> The difference between "nocall"and "not necessarily near"
> On 12/3/06, *Mark S. Miller* <markm at cs.jhu.edu 
> <mailto:markm at cs.jhu.edu>> wrote:
> 
>     John Carlson wrote:
>      > I don't know much about E, but how about 'rref' or 'remref'
>      > (maybe too much like remove instead of remote).
> 
>     Has the same problem as "rmt", "remote", "far", and "eventual": The
>     guard we
>     need does not say the reference is remote, far, or eventual, just
>     that it
>     might be. "Possibly eventual", "possibly remote", or "not
>     necessarily near"
>     captures what we'd ideally like to say, but we're still at a loss
>     for a short
>     name that expresses any of these.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> e-lang mailing list
> e-lang at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang