-discuss es-discuss@mozilla.org
Sent: Wednesday, June 1, 2011 6:48 AM
Subject: Re: ES parsing tools (Re: Short Functions)
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
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
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
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 same syntax as part of ES4 and it worked. I'm going to
update it for
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 syntax
tl;dr:
- JS-based PEG + ANTLR as a route for ES grammar experiments
- would like to know about route viability and alternative routes
If OMeta's should really be slower than similar parsers, and
the grammar-optimizing side is covered by the authors,
perhaps there is room for old-fashioned
On May 29, 2011, at 2:11 AM, Claus Reinke wrote:
tl;dr:
- JS-based PEG + ANTLR as a route for ES grammar experiments
Mark and Tom already use Ometa at a code.google.com project, as noted. What
more do you want?
This does *not* address the issue of a usable spec grammar that can be
On May 29, 2011, at 12:21 PM, Brendan Eich wrote:
Mark and Tom already use Ometa at a code.google.com project, as noted. What
more do you want?
This does *not* address the issue of a usable spec grammar that can be
validated (my point (a)). In spite of over a thousand words and many
bren...@mozilla.com
To: Claus Reinke claus.rei...@talk21.com
Cc: es-discuss es-discuss@mozilla.org
Sent: Sunday, May 29, 2011 12:55 PM
Subject: Re: ES parsing tools (Re: Short Functions)
On May 29, 2011, at 12:21 PM, Brendan Eich wrote:
Mark and Tom already use Ometa at a code.google.com project
Does Waldemar still maintain the tool? the source dates seemed fairly old...
On May 29, 2011, at 12:21 PM, Brendan Eich bren...@mozilla.com wrote:
On May 29, 2011, at 2:11 AM, Claus Reinke wrote:
tl;dr:
- JS-based PEG + ANTLR as a route for ES grammar experiments
Mark and Tom already
Mark and Tom used Ometa for http://code.google.com/p/es-lab/
http://code.google.com/p/es-lab/ -- slo-o-o-o-w.
OMeta does do memoization, but it's still slow ;-)
I'm curious: what level of slow are we talking about here?
A basic memoing top-down parser for PEG-style grammars
with good
On May 28, 2011, at 1:56 AM, Claus Reinke wrote:
If OMeta's should really be slower than similar parsers, and
the grammar-optimizing side is covered by the authors,
perhaps there is room for old-fashioned JS code optimization?
For instance, OMeta/JS is not the main line of OMeta code,
and
On May 25, 2011, at 7:57 AM, Brendan Eich wrote:
On May 25, 2011, at 5:30 AM, Lasse Reichstein wrote:
likely is not for sure. Libraries (e.g. the Array extras such as forEach)
are generally not written with finally continuing like that, even in the face
of an exception.
js
and parsers.
/be
--
*From:* Waldemar Horwat walde...@google.comwalde...@google.com
*To:* Brendan Eich bren...@mozilla.combren...@mozilla.com
*Cc:* es-discuss es-discuss@mozilla.orges-discuss@mozilla.org
*Sent:* Monday, May 23, 2011 2:09 PM
*Subject:* Re: Short
On Sun, 22 May 2011 02:56:28 +0200, Brendan Eich bren...@mozilla.com
wrote:
Why is this so bad? JS programmers return, break, and continue from
blocks all the time.
Just dawned on me that there is a significant difference.
JS blocks are executed where they are lexically located. If in a
On May 25, 2011, at 5:30 AM, Lasse Reichstein wrote:
On Sun, 22 May 2011 02:56:28 +0200, Brendan Eich bren...@mozilla.com wrote:
Why is this so bad? JS programmers return, break, and continue from blocks
all the time.
Just dawned on me that there is a significant difference.
You're
To emphasize the point... we need meat, not sugar.
And even then, maybe not even the meat.
On 22/05/2011, at 10:28 AM, Isaac Schlueter wrote:
I very much want short functions. However, the semantics of
JavaScript lambdas are so wonderfully simple.
Adding a semantically different callable
On Sun, May 22, 2011 at 7:35 PM, Brendan Eich bren...@mozilla.com wrote:
On May 22, 2011, at 5:21 PM, Isaac Schlueter wrote:
Yes, I guess we are pushing opinions at each other. I'd say that they
are that bad.
I have experience only with Ruby, not SmallTalk or E. Maybe they're
handled
On 05/21/11 23:53, Brendan Eich wrote:
That's accurate. But I discounted arrow functions because to be usable, to have
the syntax you show above, requires GLR parsing (if bottom up; top-down may be
easier, haven't proven it yet).
GLR parsing would be wild in ECMAScript due to the fact that
though I realize this is not a TC39
goal.
From: Waldemar Horwat walde...@google.com
To: Brendan Eich bren...@mozilla.com
Cc: es-discuss es-discuss@mozilla.org
Sent: Monday, May 23, 2011 2:09 PM
Subject: Re: Short Functions
On 05/21/11 23:53, Brendan Eich wrote
On May 23, 2011, at 2:09 PM, Waldemar Horwat wrote:
On 05/21/11 23:53, Brendan Eich wrote:
That's accurate. But I discounted arrow functions because to be usable, to
have the syntax you show above, requires GLR parsing (if bottom up; top-down
may be easier, haven't proven it yet).
GLR
-written lexers and parsers.
/be
From: Waldemar Horwat walde...@google.com
To: Brendan Eich bren...@mozilla.com
Cc: es-discuss es-discuss@mozilla.org
Sent: Monday, May 23, 2011 2:09 PM
Subject: Re: Short Functions
On 05/21/11 23:53, Brendan Eich wrote:
That's accurate. But I discounted arrow
...@google.com
To: Brendan Eich bren...@mozilla.com
Cc: es-discuss es-discuss@mozilla.org
Sent: Monday, May 23, 2011 2:09 PM
Subject: Re: Short Functions
On 05/21/11 23:53, Brendan Eich wrote:
That's accurate. But I discounted arrow functions because to be usable, to
have the syntax you show above
Mark and Tom used Ometa for http://code.google.com/p/es-lab/ --
slo-o-o-o-w.
Yeah it has no memoization. Pretty cool nevertheless as far as what he was
able to do. Though I really like what Dave is doing on narcissus.
No credit to me on the Narcissus parser; it was originally written
IANA Rubyist, but I *think* the goal was for blocks to be downwards-only, so
that upvars could live on the stack and everything could be nice speedy. So
they had to syntactically restrict blocks to enforce that they couldn't outlive
the frame in which they were created.
As Brendan says,
On Sat, May 21, 2011 at 6:39 PM, Brendan Eich bren...@mozilla.com wrote:
Really, we're between these choices:
1. Do nothing, function + return 4ever.
2. Shorter function syntax by some abbreviation for 'function' that still
requires 'return ' followed by an expression to return a value.
On May 21, 2011, at 11:45 PM, Bob Nystrom wrote:
Isn't there also:
4. Shorter function syntax that allows a single expression body which doesn't
require return, but if it has a return, it retains the same semantics as
current JS functions.
That was my understanding of how - functions
the other is a much more radical change to the way
the language works, which I'm not altogether
convinced is a good or useful thing.
It's essential to the control abstraction programmability.
Take a look at the examples. .. Return from a block in JS
today returns from the enclosing function.
On May 22, 2011, at 7:12 AM, Claus Reinke wrote:
Again, this is just guessing based on reading the examples in the strawman -
it could be completely off the mark. Informal but complete semantics would
help to understand what is supposed to be possible and what not. Further
decisions cannot
On May 22, 2011, at 7:12 AM, Claus Reinke wrote:
For instance, block_lambdas seem to include a form of generalized jump, a
callable thing that does not return to the caller (Tennent mentioned such
things as 'sequels',
so they were probably known in Algol times, but I have
not seen them
On Sat, May 21, 2011 at 23:07, Sami Samhuri s...@samhuri.net wrote:
The semantics have shortcomings though and introducing new syntax to save a
few keystrokes is frivolous.
Cutting out many kilobytes of code from JavaScript programs by
streamlining the single-most commonly-used idiom is hardly
On May 22, 2011, at 12:18 PM, Isaac Schlueter wrote:
On Sat, May 21, 2011 at 23:07, Sami Samhuri s...@samhuri.net wrote:
The semantics have shortcomings though and introducing new syntax to save a
few keystrokes is frivolous.
Cutting out many kilobytes of code from JavaScript programs by
On Sun, May 22, 2011 at 16:05, Brendan Eich bren...@mozilla.com wrote:
Cutting out many kilobytes of code from JavaScript programs by
streamlining the single-most commonly-used idiom is hardly frivolous.
The counterargument, I don't share it but you seem to be focused on
bandwidth, is
On May 22, 2011, at 5:21 PM, Isaac Schlueter wrote:
That was the point I was trying to make. Having block-lambdas behave
like functions is not a hazard. || is enough of a differentiator,
just like function () is, only with a little less to look at.
Ok, thanks.
On Sun, May 22, 2011 at
On May 22, 2011, at 5:21 PM, Isaac Schlueter wrote:
Yes, I guess we are pushing opinions at each other. I'd say that they
are that bad.
I have experience only with Ruby, not SmallTalk or E. Maybe they're
handled better in the other two?
Could you say more than that bad, precisely how and
I very much want short functions. However, the semantics of
JavaScript lambdas are so wonderfully simple.
Adding a semantically different callable thing is a huge mistake, in
my opinion. I'd love to be able to write
{|a, b, c| a + b * c }
or even
(a, b, c) - { a + b * c
On May 21, 2011, at 5:28 PM, Isaac Schlueter wrote:
function (a, b, c) { return a + b * c }
but I really don't want to replace our existing simple semantics.
Nothing is replaced.
You mean adding new semantics for new syntax is like replacing current
semantics with current + new, which
On May 21, 2011, at 5:56 PM, Brendan Eich wrote:
On May 21, 2011, at 5:28 PM, Isaac Schlueter wrote:
function (a, b, c) { return a + b * c }
but I really don't want to replace our existing simple semantics.
Nothing is replaced.
You mean adding new semantics for new syntax is like
On May 21, 2011, at 6:13 PM, Alex Russell wrote:
On May 21, 2011, at 5:56 PM, Brendan Eich wrote:
On May 21, 2011, at 5:28 PM, Isaac Schlueter wrote:
function (a, b, c) { return a + b * c }
but I really don't want to replace our existing simple semantics.
Nothing is replaced.
You
41 matches
Mail list logo
