Re: Resuming execution contexts

[Alan Schmitt]

Hello,

On 2021-03-16 10:43, Logan Smyth  writes:

>> as this code does not seem to take an argument.
>
> The resumption state set by `GeneratorStart` does not take an argument
> because there is no way to access the first resumption value in a
> generator, though there is the `function.sent` proposal to allow that:
> https://github.com/tc39/proposal-function.sent
>
> In the case you're asking about, the `value` applies in the case of
> `GeneratorYield` https://tc39.es/ecma262/2021/#sec-generatoryield which
> does take a resumption value argument.

Thanks a lot for the clarification. So would it be correct to state that
resumptions are always passed a value, but in some cases it is not used
(the sentence there is "when evaluation is resumed for that execution
context") and in other cases it is used ("when evaluation is resumed
with a Completion completionName")? If so, could they be made uniform in
the specification text (for instance, "when evaluation is resumed for
that execution context with a Completion completionName")?

Thanks again,

Alan


signature.asc
Description: PGP signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Resuming execution contexts

[Alan Schmitt]

Hello,

I am trying to understand how the resuming of execution contexts work.
For instance, step 9 of
https://tc39.es/ecma262/2021/#sec-generatorresume says "Resume the
suspended evaluation of genContext using NormalCompletion(value) as the
result of the operation that suspended it." I can see that the code to
run would be the one created by step 4 of
https://tc39.es/ecma262/2021/#sec-generatorstart, but I do not
understand what the "using NormalCompletion(value) as the result of the
operation that suspended it" means, as this code does not seem to take
an argument.

Please let me know if this is not the right forum to ask such questions.
And thanks a lot for any help you may provide.

Best,

Alan


signature.asc
Description: PGP signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Where is the evaluation starting point in the spec?

[Alan Schmitt]

On 2019-08-17 23:03, Gus Caplan  writes:

It's worth noting that engine262 doesn't use the RunJobs 
implementation it
has, it uses a separate entrypoint in api.mjs. There is some 
work going on
to get rid of RunJobs entirely, as no implementations actually 
use it (

https://github.com/tc39/ecma262/pull/735)


Thanks, I was not aware of this PR. I guess we should not invest 
too

much effort on the jobs infrastructure at the moment.

Best,

Alan


signature.asc
Description: PGP signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Where is the evaluation starting point in the spec?

[Alan Schmitt]

Hello Cyril,

On 2019-08-17 21:29, Cyril Auburtin  
writes:


You can also have a look at 
https://github.com/engine262/engine262, an

interesting way to learn the spec


Thank you for the suggestion. Our goal is to modernize JSExplain
(https://gitlab.inria.fr/star-explain/jsexplain) to be closer to 
the
spec (as we display spec text when interpreting programs), so we 
need to

refer directly to the spec.

Best,

Alan


signature.asc
Description: PGP signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Where is the evaluation starting point in the spec?

[Alan Schmitt]

On 2019-08-15 10:53, Alan Schmitt  
writes:



Back in ES5.1, there was a specification to evaluate programs
(https://www.ecma-international.org/ecma-262/5.1/index.html#sec-14).
What is the corresponding starting point in the current spec? Is
it
https://tc39.es/ecma262/#sec-scripts ?


Thanks to the handy Reference links in the spec, I found it:
https://tc39.es/ecma262/#sec-runjobs

Sorry for the noise.

Best,

Alan


signature.asc
Description: PGP signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Where is the evaluation starting point in the spec?

[Alan Schmitt]

Hello,

Back in ES5.1, there was a specification to evaluate programs
(https://www.ecma-international.org/ecma-262/5.1/index.html#sec-14).
What is the corresponding starting point in the current spec? Is 
it

https://tc39.es/ecma262/#sec-scripts ?

Best,

Alan


signature.asc
Description: PGP signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is Narcissus dead?

[Alan Schmitt]

On 2017-02-15 21:54, Alex Vincent  writes:

> Ouch. With ES6 and now ES7 released, I am curious as to whether
> someone has a fork out there which implements the recent standards. I
> couldn't find one...

We don't implement the recent standards in JSExplain
(https://github.com/jscert/jsexplain) but we plan to. We are currently
working on adding proxies.

Best,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂, Mauna Loa Obs. 2017-01: 406.13, 2016-01: 402.52


signature.asc
Description: PGP signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: {}+{} incosistency

[Alan Schmitt]

On 2016-04-13 19:53, Vic9  writes:

> if "{}+{}" is a statement, than how can it return (or yield) a result?

It returns a completion record, like every other construction
(http://www.ecma-international.org/ecma-262/6.0/#sec-completion-record-specification-type).
In most cases you don't get to see the value inside, but you can get to
it through eval.

In fact, I often use eval when I don't know if a console is running my
code as an expression or as a statement, as eval runs code as programs.
Running eval("{}+{}") and eval("({}+{})") nicely shows the two correct
results, which boils down to whether {} is a block
(http://www.ecma-international.org/ecma-262/6.0/#sec-block) with a
single empty statement, or if it's an object literal.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂ (2016-03, Mauna Loa Obs.): 404.83


signature.asc
Description: PGP signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: IsValidSimpleAssignmentTarget equivalent for delete?

[Alan Schmitt]

On 2015-07-31 06:26, Claude Pache claude.pa...@gmail.com writes:

 The `delete` operator applied to a non-reference just does nothing (no error
 is thrown), whereas an assignment to a non-reference did throw an error.
 I guess that there is some BC risk for trying to turn a non-error into an
 early error, not worth the advantage?

It makes sense. Thank you for the reply.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Last week athmospheric CO₂ average (Updated July 26, 2015, Mauna Loa Obs.):
401.25 ppm


signature.asc
Description: PGP signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

IsValidSimpleAssignmentTarget equivalent for delete?

[Alan Schmitt]

Hello,

ES6 introduces IsValidSimpleAssignmentTarget to make an early error the
attempt to assign to something that is obviously not a reference. For
instance

#+begin_src javascript
((function () { throw 42 })()) = 3;
#+end_src

is now a syntax error.

Is there a reason why the same does not apply to the delete operator,
such as in the following ?

#+begin_src javascript
delete ((function () { throw 42 })())
#+end_src

Thanks,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Last week athmospheric CO₂ average (Updated July 26, 2015, Mauna Loa Obs.):
401.25 ppm


signature.asc
Description: PGP signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Move es-discuss to discuss.webplatform.org?

[Alan Schmitt]

On 2015-06-20 16:14, Eric B neuros...@gmail.com writes:

 The main problem I have with mailing lists is that, unless I'm mistaken, I
 cannot unsubscribe from specific threads. As an example, The Tragedy of the
 Common Lisp, or, Why Large Languages Explode is now 33 replies deep and I
 really don't care about it at all and would rather not get spammed by that
 thread. Is there a way for me to unsubscribe from it currently?

I know how to do it with gnus
(https://www.gnu.org/software/emacs/manual/html_node/gnus/Scoring.html),
other email clients may also have this feature.

Best,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Weekly CO₂ average (2015-05-30, Mauna Loa Observatory): 403.41 ppm


signature.asc
Description: PGP signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: let function

[Alan Schmitt]

On 2015-05-19 18:24, Steve Fink sph...@gmail.com writes:

 On 05/19/2015 12:23 AM, Alan Schmitt wrote:
 On 2015-05-19 06:09, Bergi a.d.be...@web.de writes:

 Alternatively just use a single equals sign with a parameter list:

 let f(x) = y
 let f() = y
 This looks very nice indeed.

 That visually collides with destructuring for me.

 let [a, b] = foo();
 let {a, b} = foo();
 let f(a, b) = foo(); # Very different

 I almost expect that last one to use f as a custom matcher of some sort, given
 the previous two.

It is actually how it works in Ocaml: in let f p = …, p is a pattern,
which may destructure tuples such as the pair (a,b) above, or other
constructs as long as they are not part of an alternation (where several
cases may occur).

Best,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7


signature.asc
Description: PGP signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: let function

[Alan Schmitt]

On 2015-05-19 06:09, Bergi a.d.be...@web.de writes:

 Alternatively just use a single equals sign with a parameter list:

 let f(x) = y
 let f() = y

This looks very nice indeed.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7


signature.asc
Description: PGP signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: loop unrolling and completion values in ES6

[Alan Schmitt]

On 2015-04-08 16:59, Allen Wirfs-Brock al...@wirfs-brock.com writes:

 Well, they do for normal loop completions (according to the spec.) but not for
 breaks. I this the latter is a bug. In particular, I think it is pretty
 obvious that:
eval(“ {0; while (true) {1; break}; 2}”)
 should evaluate to 1

 It is a little less obvious for:
eval(“{0; L: while (true) {1; while (true) {2; break L; 3}; 4}; 5}”)

 but, I think that consistency with the first case requires this to
 evaluate to 2.

I think these cases are already fine (modulo the final expression
statement, ; 2 and ; 5, which should not be there as Brendan said):
since the body of the while is a block, the return value is patched as
expected in the block evaluation semantics (step 5):

1. Let sl be the result of evaluating StatementList.
2. ReturnIfAbrupt(sl).
3. Let s be the result of evaluating StatementListItem.
4. If s.[[type]] is throw, return Completion(s).
5. If s.[[value]] is empty, let V = sl.[[value]], otherwise let V = s.[[value]].
6. Return Completion{[[type]]: s.[[type]], [[value]]: V, [[target]]: 
s.[[target]]}.

The problem happens when the first statement of the body of the while
loop is a break: in that case the value from the previous iteration is
not carried over.

 So, it’s arguably a bug that the ES6 spec. hasn’t changed in that regard
 relative to ES3/5.

I looked deeper into the differences between ES5 and ES6, and something
has partially changed, as illustrated by this example:

  eval(var x=1; 12; while(true){ if (x) { x--; 42 } else { break } })

In ES5 and in implementations this returns 42, in ES6 this returns
undefined. The difference is here:

ES5 (12.6.2):

2. Repeat
   a. Let exprRef be the result of evaluating Expression.
   b. If ToBoolean(GetValue(exprRef)) is false, return (normal, V, empty).
   c. Let stmt be the result of evaluating Statement.
   d. If stmt.value is not empty, let V = stmt.value.
   e. If stmt.type is not continue || stmt.target is not in the current
  label set, then
  i. If stmt.type is break and stmt.target is in the current label
 set, then
 1. Return (normal, V, empty).
  ii. If stmt is an abrupt completion, return stmt.

In the example, 2.d does not apply for the second iteration of the loop
(the returned value is empty), and we are in the 2.e.i.1 case (local
break) so the returned value is patched in the completion statement.

ES6 (13.0.7 and 13.6.2.6)

the evaluation of the second iteration of the loop ends like this:
  e. Let stmt be the result of evaluating Statement.
  f. If LoopContinues (stmt, labelSet) is false, return Completion(stmt).

at this point we return (break, empty, empty) to the evaluation of the
iteration statement, which transforms it into a (normal, undefined,
empty).

The example I gave is different. Adapting it so that is resembles the
previous one:

  eval(var x=1; a: { 12; while(true) { if (x) { x--; 42} else { break a; } } 
})

This returns 12 in both ES5 and ES6 (the 12 gets patched in because of
the outer block evaluation), so the labeled statement conversion of
empty to undefined does not kick in.

 Does this inconsistency matter?

 Probably. In ES6 we are trying to “reform” completion values so, among other
 things, program transformaions do have to worry too much about breaking the
 specified specified completions values.

We found this by looking into loop unrolling, so it would be great if
completion values could propagate across loop iterations.

Best,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7


signature.asc
Description: PGP signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

loop unrolling and completion values in ES6

[Alan Schmitt]

Hello,

I've been looking into completions records in ES6, and I have a question
regarding loop unrolling, as it seems completion records are dealt with
differently for breaks inside loops and breaks inside blocks.

For while loops, the spec says (this is the part that applies to
a break in the statement, as in that case LoopContinues is false):

e. Let stmt be the result of evaluating Statement.
f. If LoopContinues (stmt, labelSet) is false, return Completion(stmt).

For blocks, the spec says:

StatementList : StatementList StatementListItem

1. Let sl be the result of evaluating StatementList.
2. ReturnIfAbrupt(sl).
3. Let s be the result of evaluating StatementListItem.
4. If s.[[type]] is throw, return Completion(s).
5. If s.[[value]] is empty, let V = sl.[[value]], otherwise let V = s.[[value]].
6. Return Completion{[[type]]: s.[[type]], [[value]]: V, [[target]]: 
s.[[target]]}.

The difference between the two is the following: if there is a break
carrying the empty completion value in a while statement, then it is
returned as such. For blocks, the completion value is patched with the
current value (V in the algorithm above).

According to the spec, the following code has a completion value of
1 (the completion record of the while is (break,empty,a), it gets
patched to (break,1,a) in the inner block, and the labeled statement
return (normal, 1,empty) which is also the final completion record).

#+begin_src javascript
var c;
a: {
  c=1;
  while(true){
if (c)
  c=0;
else
  break a;
  }
}
#+end_src


If we unroll one iteration of the loop, we get this code:

#+begin_src javascript
var c;
a: {
  c=1;
  if (true) {
if (c)
  c=0;
else
  break a;
while(true){
  if (c)
c=0;
  else
break a;
}
  }
}
#+end_src

Now the completion record is (normal,0,empty): since the assignment
c=0 is run outside the while loop, the value 0 gets patched in the
completion record, so the 1 is not patched in.

Is there a motivation for this difference of completion values between
while loops and blocks?

Thanks,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7


signature.asc
Description: PGP signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: is [[Prototype]] of global object intentionally unspecified?

[Alan Schmitt]

Hi Michael,

es-disc...@michael.ficarra.me writes:

 Oh, sorry for the duplicate. It appears you guys were just recently
 discussing this, though it failed to turn up in my searches. 

The discussion only started on test262. If it's going to entice a spec
change, it's great to talk about it here. Thanks a lot!

Best,

Alan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: is [[Prototype]] of global object intentionally unspecified?

[Alan Schmitt]

(Sorry for the latency, but I only get internet access by tethering
here.)

bruan...@gmail.com writes:

 Le 05/08/2013 17:08, Brendan Eich a écrit :
 Michael Ficarra wrote:
 specified that the global object's prototype chain must include 
 Object.prototype. I am sure there's plenty of code that depends on that.
 Concern shared.

 Yes, that's required.
 Would it make sense to leave ECMAScript spec intact (global's 
 [[Prototype]] is implementation-dependent), but have WebIDL put 
 requirements on the prototype chain?
 That would allow non-web contexts to have null as [[Prototype]]; and 
 some people seem to want to do that [1].

We don't advocate for any specific case, and we could easily change our
implementation to use something other than null for the prototype of the
global object. This case came up while looking at the tests we fail, and
we simply wanted to clear it up.

Best,

Alan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: is [[Prototype]] of global object intentionally unspecified?

[Alan Schmitt]

Hello,

es-disc...@michael.ficarra.me writes:

 It has recently come to my attention that, though Object.prototype is in
 the prototype chain of the global object in all interpreters I've ever
 used, the [[Prototype]] of the global object is actually unspecified. My
 question: was this property intentionally unspecified to allow for
 interpreters to use other objects (or null) as the [[Prototype]] of the
 global object? If so, it'd be great to add a note to the spec. If not, I'd
 be glad to open a bugzilla bug to correct the omission. Either way, I think
 the spec should explicitly mention this value.

Here is the related bug report for the test262 test that also assumes
this.

https://bugs.ecmascript.org/show_bug.cgi?id=1600

Best regards,

Alan Schmitt
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss