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 wrote:
>
> On Oct 27, 2011, at 3:08 AM, Axel Rauschmayer wrote:
>
>> +1. Where the spec is already almost pseudo-code, its readability
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
b
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
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.
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
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 implemen
+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, Sche
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
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 as ES1 (although there was a marked
> de-spaghettification
to:es-discuss-boun...@mozilla.org] On
Behalf 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 wrote:
> +1. Where the spec is already almost pseudo-code, its readability
> +w
> 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
On 27 October 2011 13:35, David Bruant 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 an exist
>> +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, Smal
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 existing
+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, etc.)
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 in
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
itted 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 te
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
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.
> >
> &
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 acti
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
22 matches
Mail list logo
