Mark S. Miller wrote:
If a block contains revealed declarations, then the block's revealed
value is a new non-extensible object whose properties mirror these
declared variable names. A revealed const is simply a copy of the
same value. For var, let, and function, the property is an
accessor
Lex Spoon wrote:
On Mon, Dec 8, 2008 at 4:08 AM, Yuh-Ruey Chen maian...@gmail.com wrote:
Jon Zeppieri wrote:
So, unless people want to expand the expression grammar significantly,
I think the expression body is a nonstarter.
How feasible would it be to make JS a pure expression
Breton Slivka wrote:
On Sat, Dec 6, 2008 at 9:57 AM, Michael Day [EMAIL PROTECTED] wrote:
(1) Expression lambdas: lambdas whose body is an expression.
var x = lambda(y, z) y + z
Solves the problem with completion leakage, solves the nested
return/break/continue issue. However, quite
Jon Zeppieri wrote:
The only problem with the proto-proposal to limit lambda bodies to
expressions (which is otherwise a good idea) is that the ES expression
sub-language isn't powerful enough. The ternary expression is awful
for conditionals more complex than if a then b else c. Without a
Most people on this list consider automatic semicolon insertion
something of a mistake. However, I think this feature would be fine if
it were not so eager and thus causing all sorts of subtle errors and
hampering language evolution (e.g. the ongoing lambda discussion). By
eager, I mean that there
Eric Suen wrote:
Your proposal make nosense to me, first, I not sure what is your
strict mode means, because in strict mode there is no automatic
semicolon insertion.
in must examples you give there is no automatic semicolon insertion,
your proposal make thing even worse, these are just
Alex Russell wrote:
Indeed, it can look like an expression to begin a name assignment:
var thinger = {(foo+bar): ... };
Has a syntax like this been shot down yet?:
var thinger = {{ foo, bar }: ... };
Since objects (much less literals) aren't used as keys in hashes
often, this
Yuh-Ruey Chen wrote:
Brendan Eich wrote:
C# uses (a, b, c) = ... but in JS the comma operator makes that
nasty to parse top-down. I think the only candidates have to be of
the form
^(a, b, c) {...}
(^ could be another character, but it seems to beat \ as others have
noted), or else
I've been casually following this discussion, and I can't help but rail
against the inherent limitations of ES's C heritage.
From the control abstraction standpoint, although {||...} gets close to
that goal, the discrepancy from true {...} control syntax stands out
like a sore thumb to me. And
David-Sarah Hopwood wrote:
Yuh-Ruey Chen wrote:
Now that I think about it, would it truly be necessary for lambda to
create an implicit block scope in the first place?
It's not strictly necessary, but it's quite ugly not to. We are intending
to restrict 'eval' precisely to remove
David-Sarah Hopwood wrote:
Yuh-Ruey Chen wrote:
Then what about this example?
// global scope
if (cond) // suppose it's true
y = 'f';
I think you meant
y = f;
No, I mean what is written: y is assigned the string f. The example
would not make any sense if it were
David Herman wrote:
My question was whether the semantics of break and continue would
support the following:
Yes, this is another good case to consider. Thanks for pointing it out; I'll
add this to the strawman:lambdas proposal. Essentially this is another aspect
of the semantics of
Hallvord R. M. Steen wrote:
On Fri, 26 Sep 2008 19:58:27 +0200, liorean [EMAIL PROTECTED] wrote:
2008/9/26 Erik Arvidsson [EMAIL PROTECTED]:
I know that Opera on mobile phones used to return a string
representation that did not reflect the original.
Yeah. Opera Mobile returned
Yes, Dave Herman already mentioned that, and I replied with this:
While this is true, this is far less of a problem than opt-in local
scoping, because the errors with opt-out local scoping are always going
to be local to the block/function the variable was assigned in.
Because of this, I believe
) {
let lineNum = 0;
for (let line in input.readLines()) {
if (line == x)
return [file, lineNum];
lineNum++;
}
}
}
}
Hope that all made sense.
-Yuh-Ruey Chen
nonlocal; // notice that these pragmas can be local
to blocks
mean = sum / lst.length;
}
return [lst.length, sum, mean];
}
---
I should also point out that this is not a radical new concept. Both
Ruby and Python have had this functionality for a while. Comments?
-Yuh-Ruey Chen
Dave Herman wrote:
I think you're still going to have the same subtleties as hoisting with
this proposal, since all the variables assigned to in the block will be
in scope for the whole block; so they'll be `undefined' before being
assigned to and there will still be the same closure
17 matches
Mail list logo
