Surprise list

2011-04-20T01:04:59Z

108.56.174.60: /* For-loop pattern failure is not an error */

Potentially surprising parts of the [[E language]].

Current as of [http://www.erights.org/download/0-8-29/ E 0.8.33o].

Very true! Makes a chagne to see someone spell it out like that. :)

==<code>def x</code> doesn't return <var>x</var>==

The forward declaration expression, <code>def <var>var</var></code>, does not return <var>var</var> but rather the [[Resolver]] for it.

===Examples===

# E sample

? def x
# value: <Resolver>

? x
# value: <Promise>

===Rationale===

If you want to pass a resolver as an argument, using it as an “out parameter”, this syntax is helpful:

x.hereIsAResolver(def y)
<var>... use y</var>

===Alternative===

If you want the actual promise, simply write <code>(def x; x)</code>.

==Unresolved references do not necessarily behave as their future resolved identity==

— messages sent before the reference is resolved may be reacted to however the current holder of the reference “arrow-head” chooses, which does not necessarily correspond to the reference to which the unresolved reference resolves.

This has been discussed in [http://www.eros-os.org/pipermail/e-lang/2005-July/010821.html an e-lang thread].

===Rationale===

This cannot be fixed without removing [http://www.erights.org/elib/distrib/pipeline.html pipelining], eliminating one of the major benefits of the E reference model.

===Examples===

For now, see [http://www.eros-os.org/pipermail/e-lang/2005-July/010827.html this lengthy example by MarkM].

===Alternative===

To avoid being vulnerable to this type of misbehavior, do not use a sameness test (<code>==</code>) or Map key lookup in order to decide on the reliability of the response to a ''previously'' sent message. This might involve using a when-catch/whenResolved construct to wait until the reference is resolved.

==Accumulator operator is lowest-precedence==

As you can see in the following expansion, the operator following the “_” is always lowest-precedence (as it is the one effectively rewritten into an assignment form):

? e`pragma.enable("accumulator"); accum 0 while (a) { _ * b + c }`
# value: e`null
...
# accum__1 := accum__1.multiply(b.add(c))
...

===Rationale===

None known; this is probably an accident of the definition of the expansion of accumulator syntax.

===Alternative===

Avoid accumulator syntax when the accumulation cannot be expressed as a single call.

== Shadowing function arguments ==

Rebinding a name within a block is an error, e.g.

def foo() {
def x := 2
def x := 3
}

("Failed: x already in scope")

However, rebinding an argument does not issue any warning:

def foo(x) {
...
def x := 2
...
println(x)
}

=== Rationale ===

The already-in-scope error is intended to catch accidentally using the same name twice, not prohibit rebinding. Generally, you can expect it to be supressed anywhere there is visible <code>{...}</code> syntax.

== Single-letter uriGetters are a special case ==

It is not possible to refer to a single-letter uriGetter in a URI literal.

? def <t> := ["foo" => "bar"]
# value: ["foo" => "bar"]

? interp.setExpand(true)
? <t:foo>
# expansion: file__uriGetter.get("t:foo")

# value: <file:/Users/kpreid/t:foo>

===Rationale===

This is a feature intended for convenient support for Windows drive letter filenames. {{XXX|Look at whether MarkM agreed to remove it.}}

===Alternative===

Use names longer than one letter.

[[Category:E language]]

Erights - User contributions [en]

Surprise list