[e-lang] Naming convention for variable holding an eventual reference

[Tyler Close]

We have a longstanding open issue in the various object capability
languages over how to name a variable that holds a reference that
should only be expected to support eventual operations. The goal of
such a convention is to communicate to the programmer that:
    - an immediate call should not be expected to succeed
    - in ref_send, that an operation is expected to be eventual, and
so no side-effects will happen right away and the normal flow of
control will continue.

The E language uses the term "rcvr" for the corresponding guard, and I
assume as the variable name suffix. AFAICT, no one is very happy about
it:

http://www.eros-os.org/pipermail/e-lang/2006-December/011646.html

In the ref_send library, in both Java and Javascript, the variable
name is suffixed with '_'.

AFAIK, Caja doesn't yet have remote references and so hasn't yet faced
this issue. It has, however, helpfully outlawed the ref_send
convention, to MarkM's everlasting shame. ;) The Cajita subset of Caja
also inherits this convention, though the rationale was lost as part
of the subsetting operation.

ADsafe also doesn't yet have remote references, but the ref_send
convention is legal.

I'm currently thinking about how to make the ref_send library play
nicely with Caja and ADsafe and so am freshly perplexed by this
problem. We kicked around some possibilities recently, which were a
suffix of: "E" or "_E". I'm not terribly thrilled with either of these
and am looking for alternatives. I suggest we test alternatives by
applying them to the sample code at:

http://waterken.sourceforge.net/bang/

I think we are looking for either a prefix or a suffix composed of
characters from [0-9a-zA-Z]. It's probably not ideal to use the '_'
character due to MarkM's shenanigans. ;)

My kick at the can is a suffix of 'z', since the character kind of
looks like the current flow of control, the top line, yielding the
start of a later flow of control, the diagonal line down to the lower
line. So:

var pagez = z.connect(window.location.toString()).
var drumz = pagez.post('subject', [])
var hitsz = drumz.get('hits')

drumz.post('bang', [ 1 ])

drumz.get('hits').when(function (value) {
    print(value);
}, function (reason) {
    print('rejected: ' + reason);
})

z.when(drumz.get('hits'), function (value) {
    print(value);
}, function (reason) {
    print('rejected: ' + reason);
})

hitsz = drumz.post('bang', [ 3 ]).get('hits')

AFAIK, there's no existing meaning for, or prohibition against, the
use of the character 'z' in variable names. The character sequence
"z." also still looks vaguely operator like, as "_." did. General
meanings for the character include:
    - compression
    - <http://en.wikipedia.org/wiki/Z_notation>
    - In Shakespeare's King Lear, Z is used as an insult. A character
is called "Thou whoreson zed! Thou unnecessary letter!"
    - Zoro's mark
    - third axis in geometry
    - see also <http://en.wikipedia.org/wiki/Z_%28disambiguation%29>

Alternatively, I could just bet against Caja and use the '_'
convention for ADsafe, Javascript, Java and hope the Caja convention
is a localized peculiarity.

--Tyler

--
"ref_send API"
http://waterken.sourceforge.net/javadoc/org/ref_send/promise/eventual/Eventual.html