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
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[David-Sarah Hopwood]

Tyler Close wrote:
> 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.

I'd prefer 'Z' to 'z' (since there are words that end in 'z'), but
neither look very mnemonic to me.

> 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.

Jacaranda (the spec for which has been coming on by leaps and bounds
recently) also needs a convention for marking private variables. If it
were not for Caja, I'd definitely choose leading '_' (which appears to
be by far the more common convention "out on the web", internal Google
conventions notwithstanding), but I don't want to be gratuitously
inconsistent with Caja.


PS. thanks for posting something about this; I intended to but other
things came up.

--
David-Sarah Hopwood
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Sandro Magi-3]

I believe JavaScript allows $ in names. The following are all valid
identifiers from my tests:

var $tmp;
var tmp$;
var $tmp$;
var $t$mp$;
var tmp_$;

$ seems like a fairly recognizable symbol, particularly as a suffix.

Sandro

Tyler Close wrote:

> 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
> _______________________________________________
> e-lang mailing list
> e-lang@...
> http://www.eros-os.org/mailman/listinfo/e-lang

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[David-Sarah Hopwood]

Sandro Magi wrote:
> I believe JavaScript allows $ in names. The following are all valid
> identifiers from my tests:
>
> var $tmp;
> var tmp$;
> var $tmp$;
> var $t$mp$;
> var tmp_$;

Yes, although you should be looking at the spec *as well as* testing :-)
<http://www.ecma-international.org/publications/standards/Ecma-262.htm>

> $ seems like a fairly recognizable symbol, particularly as a suffix.

Section 7.6 of ECMA-262 3rd ed. says:

# [...] The dollar sign ($) and the underscore (_) are permitted
# anywhere in an identifier. The dollar sign is intended for use only
# in mechanically generated code.

OTOH, that intention is widely flouted, e.g. by libraries such as
Prototype.

--
David-Sarah Hopwood
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[David-Sarah Hopwood]

David-Sarah Hopwood wrote:

> Sandro Magi wrote:
>> I believe JavaScript allows $ in names. The following are all valid
>> identifiers from my tests:
>>
>> var $tmp;
>> var tmp$;
>> var $tmp$;
>> var $t$mp$;
>> var tmp_$;
>
> Yes, although you should be looking at the spec *as well as* testing :-)
> <http://www.ecma-international.org/publications/standards/Ecma-262.htm>
>
>> $ seems like a fairly recognizable symbol, particularly as a suffix.
>
> Section 7.6 of ECMA-262 3rd ed. says:
>
> # [...] The dollar sign ($) and the underscore (_) are permitted
> # anywhere in an identifier. The dollar sign is intended for use only
> # in mechanically generated code.
>
> OTOH, that intention is widely flouted, e.g. by libraries such as
> Prototype.

Based on <http://waterken.sourceforge.net/bang/>:
----------
// Turn the URL for the current page into a remote reference
var page$ = $.connect(window.location.toString())

// The test page is a factory object for constructing a
// org.waterken.bang.Drum object. A Drum is just a counter object that can
// be incremented. We'll create a new Drum by invoking the factory method.
var drum$ = page$.post('subject', [])

// By convention, the name of a variable holding a promise is suffixed
// with an '$' character. When following this convention, you can recognize
// ansynchronous operations by looking for the '$.' character sequence.
var hits$ = drum$.get('hits')

// Since I'm just typing in an interactive shell, the response to the GET
// request sent above will already have been received and processed by the
// time I hit the 'Enter' key.
hits$

0

// Send a POST request to increment the counter...
drum$.post('bang', [ 1 ])
----------

Doesn't look too bad, if a bit more visually noisy than _.

However,
  - ideally we want a convention that can be used across several languages,
    including E, Java/Joe-E, Emily, etc. as well as subsets of Javascript.
    Most languages, following the Unicode identifier recommendations (or
    something more restrictive), do not allow '$' after the first character.

  - in Javascript, using just '$' as the name of the "eventual operator"
    conflicts with a convention used in Prototype and several other libraries
    for getting DOM nodes.

--
David-Sarah Hopwood
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Sandro Magi-3]

David-Sarah Hopwood wrote:
>> Yes, although you should be looking at the spec *as well as* testing :-)
>> <http://www.ecma-international.org/publications/standards/Ecma-262.htm>

Ah, but checking specs is not productive when one is trying to go to
bed. :-)

> However,
>   - ideally we want a convention that can be used across several languages,
>     including E, Java/Joe-E, Emily, etc. as well as subsets of Javascript.
>     Most languages, following the Unicode identifier recommendations (or
>     something more restrictive), do not allow '$' after the first character.
>
>   - in Javascript, using just '$' as the name of the "eventual operator"
>     conflicts with a convention used in Prototype and several other libraries
>     for getting DOM nodes.

_ seems like the only truly cross-language non-alphanumeric identifier.

Sandro
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Tyler Close]

We spent some more time kicking around this problem this morning and
finished with the following proposal.

Instead of making Javascript promises directly invokable, as in:

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

we make all eventual invocations via a global object, so:

Q.post(drum, 'bang', [ 1 ])

The 'drum' reference can be either a promise or an immediate
reference; either way, the invocation is still an eventual invocation.
There's now less of a need for a naming convention for the 'drum'
variable, since it's immediately apparent that this is not an
immediate call on the referenced object; the Q object determines the
flow of control.

So the example code becomes:

var page = Q.connect(window.location.toString())
var drum = Q.post(page, 'subject', [])
var hits = Q.get(drum, 'hits')

Q.post(drum, 'bang', [ 1 ])

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

hits = Q.get(Q.post(drum, 'bang', [ 3 ]), 'hits')

I think the last line is the only one that presents a significant
concern. In the current syntax, it's:

hits_ = drum_.post('bang', [ 3 ]).get('hits')

On the wire, the GET request follows the POST request, which is
expressed nicely in the current syntax, but less so in the proposed
new syntax. This inversion happens to the whole chain of calls in the
statement. The effect is limited to the statement though and doesn't
cause a similar inversion in the code block.

I think the proposed syntax plays nicely in either Caja or ADsafe. The
Java ref_send API would remain unchanged.

Is this better than what we've got now? Any more improvement to be made?

--Tyler
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Raoul Duke]

> Q.post(drum, 'bang', [ 1 ])

>From the perspective of a newbie looking at code which uses that
style, it sure uses an awful lot of "Q.fn(" everywhere which looks to
make the code less readable (if perhaps more robust in other ways).
Not that I have a constructive alternative to offer.

sincerely.
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Tyler Close]

On Fri, May 16, 2008 at 3:07 PM, Raoul Duke <raould@...> wrote:
>> Q.post(drum, 'bang', [ 1 ])
>
> From the perspective of a newbie looking at code which uses that
> style, it sure uses an awful lot of "Q.fn(" everywhere which looks to
> make the code less readable (if perhaps more robust in other ways).
> Not that I have a constructive alternative to offer.

Ya, that bothers me too. It can be made a little better by adding the
following preamble to your Javascript file:

var post = Q.post;
var get = Q.get;
var when = Q.when;

The code then becomes:

var page = Q.connect(window.location.toString())
var drum = post(page, 'subject', [])
var hits = get(drum, 'hits')

post(drum, 'bang', [ 1 ])

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

hits = get(post(drum, 'bang', [ 3 ]), 'hits')

Just removing most of the capital Q's, seems to be a lot less
distracting. I suspect this can't be the default though, because
adding lots of variables to the global Javascript scope is frowned
upon.

--Tyler
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Toby Murray-4]

On Fri, 2008-05-16 at 15:21 -0700, Tyler Close wrote:

> On Fri, May 16, 2008 at 3:07 PM, Raoul Duke <raould@...> wrote:
> >> Q.post(drum, 'bang', [ 1 ])
> >
> > From the perspective of a newbie looking at code which uses that
> > style, it sure uses an awful lot of "Q.fn(" everywhere which looks to
> > make the code less readable
> Ya, that bothers me too. It can be made a little better by adding the
> following preamble to your Javascript file
>
> var page = Q.connect(window.location.toString())
> var drum = post(page, 'subject', [])
> var hits = get(drum, 'hits')
>
> post(drum, 'bang', [ 1 ])
>
> when(get(drum, 'hits'), function (value) {
>   print(value);
> }, function (reason) {
>   print('rejected: ' + reason);
> })
>

This still looks worse (to me) than the original.

Can someone elaborate on the problem with _ in Caja?

Could one use "_r" (remote, or "ref") as a suffix instead? I presume
this sort of thing has been dismissed for reasons unknown.

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Tyler Close]

On Fri, May 16, 2008 at 3:32 PM, Toby Murray
<toby.murray@...> wrote:
> Can someone elaborate on the problem with _ in Caja?

Caja defines a trailing _ to be the semantic equivalent of Java's
'private' keyword. Apparently Google has been using this convention
internally for a very long time.

> Could one use "_r" (remote, or "ref") as a suffix instead? I presume
> this sort of thing has been dismissed for reasons unknown.

We haven't found a suffix that we like.

--Tyler
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Tyler Close]

Another advantage of routing all invocations through a global Q object
is that we can reserve the API on the promise objects. In the event
that Javascript ever becomes an actual dynamic language with a
doesNotUnderstand handler, we can upgrade to the syntax we'd really
like:

var page_ = _.connect(window.location.toString())
var drum_ = page_.subject()
var hits_ = drum_.getHits()

drum_.bang(1)

_.when(drum_.getHits(), function (value) {
   print(value);
}, function (reason) {
   print('rejected: ' + reason);
})

hits_ = drum_.bang(3).getHits()

Which is much like the syntax we have in the version of the ref_send
API for Java, a much better dynamic language than Javascript. ;)

--Tyler
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[David-Sarah Hopwood]

Tyler Close wrote:

> Instead of making Javascript promises directly invokable, as in:
>
> drum_.post('bang', [ 1 ])
>
> we make all eventual invocations via a global object, so:
>
> Q.post(drum, 'bang', [ 1 ])
>
> The 'drum' reference can be either a promise or an immediate
> reference; either way, the invocation is still an eventual invocation.
> There's now less of a need for a naming convention for the 'drum'
> variable, since it's immediately apparent that this is not an
> immediate call on the referenced object; the Q object determines the
> flow of control.
>
> So the example code becomes:
>
> var page = Q.connect(window.location.toString())
> var drum = Q.post(page, 'subject', [])
> var hits = Q.get(drum, 'hits')
>
> Q.post(drum, 'bang', [ 1 ])
>
> Q.when(Q.get(drum, 'hits'), function (value) {
>    print(value);
> }, function (reason) {
>    print('rejected: ' + reason);
> })
>
> hits = Q.get(Q.post(drum, 'bang', [ 3 ]), 'hits')
>
> I think the last line is the only one that presents a significant
> concern. In the current syntax, it's:
>
> hits_ = drum_.post('bang', [ 3 ]).get('hits')
>
> On the wire, the GET request follows the POST request, which is
> expressed nicely in the current syntax, but less so in the proposed
> new syntax. This inversion happens to the whole chain of calls in the
> statement. The effect is limited to the statement though and doesn't
> cause a similar inversion in the code block.
>
> I think the proposed syntax plays nicely in either Caja or ADsafe. The
> Java ref_send API would remain unchanged.
>
> Is this better than what we've got now? Any more improvement to be made?

['_$' below is just an example of a distinguishable prefix.]

Suppose that _$post, _$get, _$when etc. were defined on Object.prototype,
and that safe Javascript subsets had the restriction that there is no
ambient authority to set or define properties with names starting '_$'.
Assume that the ref_send library is granted explicit authority to set
these properties on Object.prototype.

That would have essentially the same effect as being able to define
_$post etc. as infix operators:

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

   hits = drum._$post('bang', [ 3 ])._$get('hits');

It would still have the property that _$post always performs an
eventual send whether called on a promise or an immediate reference.
Eventual operations would be identifiable by the use of '._$'.

When not running in a subsetted language, this would be relying on
these methods not being overridden by convention, but that is only
similar to relying on (among many other assumptions) 'Q' not being
replaced.

I didn't use plain '$' for the prefix above because a property named
'$' is used in Waterken serialization. Any distinguishable prefix
for the names of eventual operators could be used, as long as Caja,
ADsafe, etc. agree on it.

The same mechanism could also work for other cases where you want
non-overridable infix operators, for example checked arithmetic.
In that case I think you'd want to reserve distinguishable prefixes
for eventual and non-eventual operators. For example, if the
restricted prefix was '_', then '_' not followed by '$' could
indicate a non-eventual, non-overridable infix operator.

--
David-Sarah Hopwood
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[David-Sarah Hopwood]

Tyler Close wrote:

> On Fri, May 16, 2008 at 3:07 PM, Raoul Duke <raould@...> wrote:
>>> Q.post(drum, 'bang', [ 1 ])
>> From the perspective of a newbie looking at code which uses that
>> style, it sure uses an awful lot of "Q.fn(" everywhere which looks to
>> make the code less readable (if perhaps more robust in other ways).
>> Not that I have a constructive alternative to offer.
>
> Ya, that bothers me too. It can be made a little better by adding the
> following preamble to your Javascript file:
>
> var post = Q.post;
> var get = Q.get;
> var when = Q.when;

For ADsafe compatibility, that should be:

   var post = Q.getPost();
   var get = Q.getGet();
   var when = Q.getWhen();

(ADsafe.get will not return a function.)

--
David-Sarah Hopwood
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[David-Sarah Hopwood]

I wrote:
> Suppose that _$post, _$get, _$when etc. were defined on Object.prototype,
> and that safe Javascript subsets had the restriction that there is no
> ambient authority to set or define properties with names starting '_$'.

In other words, make these "final" methods of Object. A more general
mechanism for final methods would be of no use in ES3 because it is
untyped, so you couldn't rely on any given object being of a class/type
that defines a method as final.

[...]
> The same mechanism could also work for other cases where you want
> non-overridable infix operators, for example checked arithmetic.
> In that case I think you'd want to reserve distinguishable prefixes
> for eventual and non-eventual operators. For example, if the
> restricted prefix was '_',  [...]

A side effect of choosing '_' as the restricted prefix, BTW, would be
that code using leading '_' as a convention to indicate privacy would
fail to verify or cajole. That could be viewed as desirable, since the
leading '_' convention does not actually enforce privacy in any of
{ADsafe, Cajita, Caja, Jacaranda} (assuming that I end up using the
same convention as Caja for Jacaranda). The result would be to force,
or at least strongly encourage, the code to be changed to either:

  - use the lexical encapsulation pattern and delete the '_', or
  - in Caja or Jacaranda, use trailing '_' instead of leading '_'.

> [...] then '_' not followed by '$' could indicate a non-eventual,
 > non-overridable infix operator.

In case this wasn't clear, the checked arithmetic example would be
something like:

Object.prototype._add = function(y) { return caja.ensureNat(this + y); }

(3)._add(4);
// 7
(1e309)._add(4);
// throws exception

Still not pretty, in the absence of operator overloading, but the
arguments and operator are in the right order for people used to infix
(not for Lisp/Scheme programmers, of course). This only works if the
method is final, since the first argument object cannot in general
be trusted.

What I suggested in

   <http://www.eros-os.org/pipermail/e-lang/2004-August/009947.html>

would be prettier and a *lot* more flexible, but that would be a
significant language change. [It also extends easily to solving the
original problem discussed in this thread, by adding expansions such
as "x <- y(...) ==> Q.post(x, 'y', [...])".]

Perhaps unsurprisingly, operator overloading almost got added to ES4:

   <http://wiki.ecmascript.org/doku.php?id=proposals:operators>

but they made it unnecessarily complicated (of course), and
eventually dropped it in favour of (even more complicated) generic
functions. To get from the proposal on that page to my 2004 idea,

  - delete all of the steps that say "if the concrete class";
  - change intrinsic::op to __arithmetic.op;
  - don't include the === or !== operators, which should be primitive.

I would also define all of the comparison operators in terms of a
single 'compareTo' operator, like in E.

--
David-Sarah Hopwood
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Baldur Johannsson-2]

if there is no insistence on English I propose the variable name suffix "_loks".
Which is an translation of "eventual" to Icelandic.

just an small suggestion.
-Baldur Jóhannsson
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang