On Oct 27, 2011, at 3:08 AM, Axel Rauschmayer wrote:
+1. Where the spec is already almost pseudo-code, its readability would
improve if it was, in fact, pseudo-code.
I don't understand? The current spec. is pseudo-code, not almost pseudo code
(however, there are some sections that are not
Allen Wirfs-Brock wrote:
I'm again considering creating a line-by-line translation of the ES6
spec algorithms into an executable evaluator of parse trees.
Cool. So my work might help you do the translation programmatically.
this would be a non-normative translation of the spec. that could
Correct. My bad.
--
Dr. Axel Rauschmayer
rauschma.de
[Sent from a mobile device, please forgive brevity and typos]
On Oct 28, 2011, at 8:02, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Oct 27, 2011, at 3:08 AM, Axel Rauschmayer wrote:
+1. Where the spec is already almost
On Oct 26, 2011, at 5:02 PM, Michael Dyck wrote:
Brendan Eich wrote:
...
(I ask because, in my spare time, I'm developing a process that massages
the ES spec into an executable/testable form. So I wonder if I'm
duplicating existing work.)
Interesting -- you are writing an interpreter?
+1. Where the spec is already almost pseudo-code, its readability would improve
if it was, in fact, pseudo-code. But would an extra interpreter be needed or
couldn’t one just implement the ES-262 constructs (execution contexts etc.) in
an existing language (Python, Rust, Scheme, Smalltalk,
Le 27/10/2011 12:08, Axel Rauschmayer a écrit :
+1. Where the spec is already almost pseudo-code, its readability
would improve if it was, in fact, pseudo-code. But would an extra
interpreter be needed or couldn’t one just implement the ES-262
constructs (execution contexts etc.) in an
+1. Where the spec is already almost pseudo-code, its readability would
improve if it was, in fact, pseudo-code. But would an extra interpreter be
needed or couldn’t one just implement the ES-262 constructs (execution
contexts etc.) in an existing language (Python, Rust, Scheme, Smalltalk,
On 27 October 2011 13:35, David Bruant bruan...@gmail.com wrote:
+1. Where the spec is already almost pseudo-code, its readability would
improve if it was, in fact, pseudo-code. But would an extra interpreter be
needed or couldn’t one just implement the ES-262 constructs (execution
contexts
To spec a beast like ES, you want something with a considerably
simpler and cleaner semantics than ES. Otherwise, all you end up with
is a circular definition.
It mainly depends on how close you can get to true pseudo-code. With ES6’s
cleaner semantics (e.g. block scoping), I think it could
Of Andreas Rossberg
Sent: Thursday, October 27, 2011 4:48 AM
To: David Bruant
Cc: es-discuss
Subject: Re: testable specification
On 27 October 2011 13:35, David Bruant bruan...@gmail.com wrote:
+1. Where the spec is already almost pseudo-code, its readability
+would
improve if it was, in fact
is:
Switch to a testable specification, ideally
a definitional interpreter hosted mostly in ES5.
Is there much activity toward this goal? The current ES6 drafts are
using mostly the same formalism as ES1 (although there was a marked
de-spaghettification between ES3 and ES5).
(I ask because
On Oct 27, 2011, at 4:40 AM, Axel Rauschmayer wrote:
+1. Where the spec is already almost pseudo-code, its readability would
improve if it was, in fact, pseudo-code. But would an extra interpreter be
needed or couldn’t one just implement the ES-262 constructs (execution
contexts etc.) in
+1. Where the spec is already almost pseudo-code, its readability would
improve if it was, in fact, pseudo-code. But would an extra interpreter be
needed or couldn’t one just implement the ES-262 constructs (execution
contexts etc.) in an existing language (Python, Rust, Scheme, Smalltalk,
On Oct 27, 2011, at 4:35 AM, David Bruant wrote:
Le 27/10/2011 12:08, Axel Rauschmayer a écrit :
+1. Where the spec is already almost pseudo-code, its readability would
improve if it was, in fact, pseudo-code. But would an extra interpreter be
needed or couldn’t one just implement the
On Oct 27, 2011, at 12:07 PM, Axel Rauschmayer wrote:
+1. Where the spec is already almost pseudo-code, its readability would
improve if it was, in fact, pseudo-code. But would an extra interpreter
be needed or couldn’t one just implement the ES-262 constructs (execution
contexts etc.) in
On Oct 27, 2011, at 9:44 AM, Dave Fugate wrote:
+1:
* existing test case IDs for all 10K+ tests on test262 would need to updated.
This alone makes me very hesitant to suggest any modifications to the
*existing* pseudo-code algorithms
ES.next is a major revision of the ES specification.
According to
http://wiki.ecmascript.org/doku.php?id=harmony:harmony
goal #2 of Harmony is:
Switch to a testable specification, ideally
a definitional interpreter hosted mostly in ES5.
Is there much activity toward this goal? The current ES6 drafts are
using mostly the same formalism
On Oct 26, 2011, at 12:08 PM, Michael Dyck wrote:
According to
http://wiki.ecmascript.org/doku.php?id=harmony:harmony
goal #2 of Harmony is:
Switch to a testable specification, ideally
a definitional interpreter hosted mostly in ES5.
Is there much activity toward this goal
:
On Oct 26, 2011, at 12:08 PM, Michael Dyck wrote:
According to
http://wiki.ecmascript.org/doku.php?id=harmony:harmony
goal #2 of Harmony is:
Switch to a testable specification, ideally
a definitional interpreter hosted mostly in ES5.
Is there much activity toward this goal
Brendan Eich wrote:
On Oct 26, 2011, at 12:08 PM, Michael Dyck wrote:
According to
http://wiki.ecmascript.org/doku.php?id=harmony:harmony
goal #2 of Harmony is:
Switch to a testable specification, ideally
a definitional interpreter hosted mostly in ES5.
Is there much activity toward
a bug against
it. And it's great that ES has a test suite. But from the context of the
goal:
Switch to a testable specification, ideally
a definitional interpreter hosted mostly in ES5.
I got the impression that testable specification meant that one would
actually test the specification
On Oct 26, 2011, at 5:02 PM, Michael Dyck wrote:
(I ask because, in my spare time, I'm developing a process that massages
the ES spec into an executable/testable form. So I wonder if I'm
duplicating existing work.)
Interesting -- you are writing an interpreter?
Yes, but not an interpreter
22 matches
Mail list logo
