On 01.06.2011 3:06, Waldemar Horwat wrote:
On 05/29/11 07:00, Dmitry A. Soshnikov wrote:
Yeah, and ES also supports them. It's called a generator expression;
in this proposal it would look like:
let squares = (x * x | x data, x 5);
Ahem, that's already a parenthesized comma expression
On May 31, 2011, at 10:07 PM, Kam Kasravi wrote:
Is it a given that the grammar extensions in the various strawmen are all
LR(1)?
See earlier in this thread, where this strawman was mentioned as requiring
either a cover grammar for ArrowFormalParameters (namely Expression), plus a
P.S.: another question I have -- is it worth and makes sense to raise a topic
on considering/standardizing the pattern matching (Dave's proposal)?
http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching Brendan
mentioned on Twitter that it's too late (?), but IMO this proposal is
On May 31, 2011, at 2:25 PM, Allen Wirfs-Brock wrote:
This is as plausible as using ! for non-configurable as I had proposed. It
really comes down to alignment with other uses of #. It is pretty easy to
make a logical association between this mapping of symbols to meanings.
However, it
On 01.06.2011 10:57, David Herman wrote:
P.S.: another question I have -- is it worth and makes sense to raise a topic on
considering/standardizing the pattern matching (Dave's proposal)?
http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching Brendan mentioned on
Twitter that it's
On Jun 1, 2011, at 12:21 AM, Dmitry A. Soshnikov wrote:
Ah, come on, of course I didn't compare them apples-to-apples. Just said that
it's more likely that some elegant and powerful syntactic construction/sugar
will be used more often than use-cases with WeakMaps and it turns out that
much
Le 01/06/2011 01:57, Cormac Flanagan a écrit :
One possible concern with proxies is the overhead of separate proxy
and handler objects, and trap methods that likely close over a backing
object. This concern would be exacerbated in the case of value
proxies, where we might want millions of
On May 31, 2011, at 4:20 PM, Waldemar Horwat walde...@google.com wrote:
On 05/29/11 19:35, Kam Kasravi wrote:
Does Waldemar still maintain the tool? the source dates seemed fairly old...
It still works. I didn't bother updating the ES3 parser for ES5 because I
had already explored the
Hi Kam,
I've been experimenting with pegjs - which generates a parser
based on the ecma-262 5th edition grammar.
yes, pegjs [1] and jsparse [2] were the alternatives I had been looking
at. pegjs is probably a bit ahead when you just want to use the parse
result; I chose to build on jsparse
Hi Tom,
I just wanted to provide a bit more context on our Ometa experiment:
our goal was to build an executable parser whose definition was as
close as possible to the BNF in the ES5 spec, which worked out fairly
well. The main purpose of the tool was to be able to quickly experiment
with
Why not just move Arrow to the head to avoid any current or future
ArrowFormalParameters parsing issues such as the GLR issue ?
ArrowFunctionExpression :
Arrow ArrowFormalParametersOpt InitialValue
Arrow ArrowFormalParametersOpt BlockOpt
This would deviate from C# and Coffeescript
Results for IE9 (IE9 standards mode) given the snippet below:
\r : ERROR
\\u : ERROR
\\x : ERROR
\\8 : 8
\\28 : \u00028
\\228 : \u00128
\\3778 : ÿ8
\\478 : '8
\\778 : ?8
My best,
Dave
-Original Message-
From:
one thing that stands out in your proposal is that there doesn't appear to be
any way to write a recursive arrow function.
Here is one way it might be done:
higher(-: fact (n) n=1?1:n*fact(n-1));
or possibly
higher(-@ fact (n) n=1?1:n*fact(n-1));
(in either case the 3 character arrow
It seems you're rethrowing the - vs the @ syntax debate. (replace - by @
in your proposal, you'll get the initial proposal I did)
setTimeout(@alert('2s elapsed'), 2000);
setTimeout(@@this.performAction(), 5000);
function getReference() { return @@this; }
var props = objs.map(@(x)
I would propose :
return (
fact@(n) (
n=1 ?
1 :
n*fact(n-1)
)
);
Wouldn't that do the trick? I think that the @ char is not allowed in an
identifier in ES5, which mean it would not introduce any compatibility
issue.
-Message d'origine-
From: Allen
On Jun 1, 2011, at 8:30 AM, Sean Eagan wrote:
Why not just move Arrow to the head to avoid any current or future
ArrowFormalParameters parsing issues such as the GLR issue ?
There's no GLR issue if we do what we're doing for assignment expressions,
including destructuring: parse a cover
On Jun 1, 2011, at 9:17 AM, François REMY wrote:
It seems you're rethrowing the - vs the @ syntax debate. (replace - by @ in
your proposal, you'll get the initial proposal I did)
@ is wanted for private names.
There's no need to go a bikeshed- or snipe-hunt for coveted, scarce single
ASCII
On 28/05/2011, at 16:29, Brendan Eich wrote:
On May 28, 2011, at 1:49 AM, Jorge wrote:
On 27/05/2011, at 12:24, Brendan Eich wrote:
On May 27, 2011, at 2:36 AM, Jorge wrote:
Also, I wonder if in order to make blocks first class, do we need any new
syntax ?
function f() {
a.forEach({
On Jun 1, 2011, at 10:07 AM, Jorge wrote:
A block:
{ noLabelHere ... }
We didn't talk about this change. It is yet another migration early-error to
consider.
But it's not very usual to begin a block with a label.
You're right, and it can be an ArrowBodyBlock, not a backward-compatible
Last time I asked, it was the # char that was wanted for private names. If
# has been replaced by @ in private names, then we can replace @ by
# in my proposal, and return to the original proposal of #functions. If
private name uses both @ and #, I raise *severe* concerns about it. Since
On Jun 1, 2011, at 10:38 AM, François REMY wrote:
Last time I asked, it was the # char that was wanted for private names. If
# has been replaced by @ in private names, then we can replace @ by #
in my proposal, and return to the original proposal of #functions.
# is wanted for frozen/joined
Good point, the Identifier + ArrowFormalParameters would be ambiguous
with a function call. That could be fixed though by just putting the
Identifier before the Arrow:
higher( fact - (n) n=1 ? 1 : n * fact(n-1));
var warmer - (a) {...};
let warm - (b) {...};
const colder - (c) {...};
const
On 06/01/11 01:32, Kam Kasravi wrote:
On May 31, 2011, at 4:20 PM, Waldemar Horwatwalde...@google.com wrote:
On 05/29/11 19:35, Kam Kasravi wrote:
Does Waldemar still maintain the tool? the source dates seemed fairly old...
It still works. I didn't bother updating the ES3 parser for ES5
http://wiki.ecmascript.org/doku.php?id=harmony:proper_tail_calls
I notice that in the proper tail calls wiki page that a compliant
interpreter SHOULD implement a call in proper tail position as a
PTC. In order for a programmer to use proper tail calls for
arbitrarily deep recursion, the
Thanks for catching this, it goes back to
http://wiki.ecmascript.org/doku.php?id=strawman:proper_tail_callsrev=1273414092
(first rev). Cc'ing Mark. I bet it is just a thinko for MUST and we can fix it
quickly.
/be
On Jun 1, 2011, at 3:36 PM, Peter Michaux wrote:
2011/6/1 Peter Michaux petermich...@gmail.com:
Could some of JavaScript's statements also be allowed as expressions?
In Perl there is the common idiom when opening a file
open F, $f or die Can't open $f : $!;
In JavaScript could throw be an expression?
f() || throw 'f failed';
Could
2011/6/1 Waldemar Horwat walde...@google.com:
Yes, if you make it mandatory to parenthesize statements then this would
work, except for the important case of blocks.
I agree that blocks are sticky but important.
The approach below is a way to handle blocks. It's not particularly
pretty, but I
2011/6/1 Mike Samuel mikesam...@gmail.com:
( (lookahead in [break, continue, do, for, if, return, switch,
throw, try, while])
ExpressionBlock )
I'm so busy buggering up grammars that I keep forgetting debugger
but it should show here and in the EmbeddedStatement production.
28 matches
Mail list logo
