00:28:23  * AtumT_quit (Remote host closed the connection)
00:34:04  * jwaldenjoined
01:21:17  <jschoi>I’m having trouble determining precisely where in the specification is `function f () { super() }` defined as a compile-time syntax error. `super` calls (https://tc39.github.io/ecma262/#sec-super-keyword) are a type of LHS Expression (https://tc39.github.io/ecma262/#sec-left-hand-side-expressions), and neither of their clauses appear to define static early errors.
01:22:49  * caridyjoined
01:44:46  <not-an-aardvark>jschoi: looks like it's here: https://tc39.github.io/ecma262/#sec-function-definitions-static-semantics-early-errors
01:44:59  <not-an-aardvark>> It is a Syntax Error if FunctionBody Contains SuperCall is true.
01:48:28  <jschoi>Ah, so it’s in function’s clause; thanks.
01:49:18  <jschoi>So that means it would probably be in module’s and script’s respective clauses too…
01:49:32  <jschoi>…And there it is https://tc39.github.io/ecma262/#sec-scripts-static-semantics-early-errors. That explains that. Thanks again.
01:51:32  <jschoi>…And https://tc39.github.io/ecma262/#sec-performeval for direct eval, right.
01:52:30  <jschoi>And function/method definitions override `Contains` so that their body contents are opaque to `Contains`.
01:52:46  <jschoi>Except arrow functions, which are transparent for `super`. Got it.
02:59:06  * Jamesernatorjoined
03:00:53  * Jamesernatorquit (Client Quit)
04:11:31  * howdoijoined
04:41:02  <jschoi>What’s done is done, but a comment (https://github.com/tc39/proposal-optional-chaining/issues/5#issuecomment-353884817) made me curious. Any parentheses surrounding the bodies of arrow functions are significant for distinguishing between a object versus a block with a label. This is a foot gun. But the comment refers to it have being unavoidable. In a better world, how would this foot gun have been avoided?
04:42:06  <jschoi>That is: `x => ({ y: z })` (returns object) versus `x => { y: z }` (block with labeled statement).
04:44:50  <jschoi>ljharb, you made that comment, from last December, so if you happen remember what you thinking about at that time, it would be wonderfully edifying to hear an explanation.
04:50:28  * caridyquit (Remote host closed the connection)
04:50:55  * caridyjoined
04:55:27  * caridyquit (Ping timeout: 248 seconds)
04:55:51  * jmdyckquit (Remote host closed the connection)
05:04:46  * ephemera__joined
05:06:41  * ephemera_quit (Ping timeout: 248 seconds)
05:35:19  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
05:44:34  <ljharb>jschoi: i would have preferred that labeled blocks be forbidden in an arrow function body (which would have been a weird inconsistency)
05:50:42  <jschoi>ljharb: Thanks. Is the inconsistency here the prohibition of labeled blocks or the significance of parentheses around the braces?
05:50:48  * caridyjoined
05:54:57  * caridyquit (Ping timeout: 240 seconds)
05:56:58  * caridyjoined
05:58:42  <ljharb>jschoi: sorry, let me clarify
06:00:42  <ljharb>jschoi: the parens force the block/object into expression position, which forces it to be an object. because of the `x => { }` explicit return form, `{ a: b }` has no way to definitively mean "it's an object", and so the parser, when it sees the `{`, doesn't have to keep looking forward before it knows if it's a block or an object literal
06:01:20  <ljharb>jschoi: so i think that even if labels were banned in arrow function bodies, it'd still amount to a period of parsing time where the engine would have to wait-and-see if it was inside a block or inside an object literal
06:01:33  * caridyquit (Ping timeout: 264 seconds)
06:35:07  * not-an-aardvarkjoined
07:05:39  * caridyjoined
07:10:24  * caridyquit (Ping timeout: 256 seconds)
08:10:26  * caridyjoined
08:14:35  * caridyquit (Ping timeout: 240 seconds)
08:23:18  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
08:24:02  * keith_millerjoined
08:43:50  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:07:47  * keith_millerjoined
09:18:00  * caridyjoined
09:22:10  * caridyquit (Ping timeout: 240 seconds)
09:48:10  * caridyjoined
09:53:04  * caridyquit (Ping timeout: 265 seconds)
10:25:19  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
10:44:47  * caridyjoined
10:49:05  * caridyquit (Ping timeout: 240 seconds)
11:25:11  * mylesborinsquit (Quit: farewell for now)
11:25:41  * mylesborinsjoined
11:29:46  * caridyjoined
11:34:10  * caridyquit (Ping timeout: 240 seconds)
11:55:53  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:01:50  <jschoi>ljharb: Thanks for the clarification. What I’m interested in is when you remarked that the parenthesis significance for arrow-function bodies “should have been unacceptable, and could have been avoided.” How could it have been avoided, if not by forbidding labels in arrow-function blocks?
12:05:41  <jschoi>Alternatively, have you changed your mind about the how severity of footgun that parenthesis significance is? After all, if the only other viable solution (for distinguishing `{a: b}` the block from `{a: b}` the object) would have been to forbid labels, then as you point out this too has a possibly severe problem: a large-lookahead, garden-path problem. Have you decided that using significant parentheses was the best
12:05:41  <jschoi>choice after all, or is there a third solution to the object-vs.-block problem that was missed?
12:18:46  <jschoi>This design question is particularly relevant to that smart-pipe draft I’m working on. For the `body` of a pipeline `head |> body`, “simple references” to functions (i.e., `identifier` or `identifier.identifier` or `identifier.identifier.identifier`...) are distinguished from “topical expressions” (all other expressions which must contain a “topic reference” `#`) by the absence of operators, parentheses,
12:18:46  <jschoi>brackets, or braces.
12:19:30  <jschoi>It is also an early error if a “topical expression” (that is, a pipeline body that is not a “simple expression”) does not actually contain a “topic reference”. That is, `x |> f(x)` is an early error because `f(x)` is not a simple reference but does not contain `#`. This gets rid of a big footgun; I’m trying to design this so that such footguns are obviated.
12:21:45  <jschoi>But parentheses are currently significant around the pipeline body. `x |> (f)` is an early error because `(f)` is not a “simple reference” to a function; therefore it must be a “topical expression”, except that it contains no topic reference `#`, so it’s an error.
12:23:11  <jschoi>This situation somewhat resembles arrow functions’ parenthesis significance while distinguishing its own two types of bodies, bare expressions versus blocks. The garden-path parsing constraint is also still there; that’s why the “simple reference” rule is so simple and fails so easily.
12:25:52  <jschoi>I hope that the early errors I’m putting in the draft will obviate the syntax’s footguns: they will fail in as many cases of developer-intentional ambiguity I can anticipate. But because of their clear parallel to the problem of arrow-function bodies, I’d be very interested to know what your opinions on what a better syntax for arrow-function bodies would have been.
12:25:54  * AtumTjoined
12:26:51  <jschoi>Forbidding labels has the garden-path problem. Significant parentheses gives sometimes surprising behavior. Any alternatives? Are significant parentheses the best of a bad pair of solutions?
12:31:23  <jschoi>Or perhaps an additional early error?
12:31:41  <jschoi>What would have been a better syntax for arrow-function bodies than significant parentheses, in a counterfactual better world?
12:43:53  * jmdyckjoined
12:44:52  <jschoi>One third possible solution (for distinguish between expression versus block arrow-function bodies) that I see would have been to split the arrow function into two operators like `=>` and `==>`. This would have been a similar solution to the “split-mix” pipe operator proposal.
12:45:14  <jschoi>*for distinguishing
12:46:03  * caridyjoined
12:50:41  * caridyquit (Ping timeout: 248 seconds)
13:24:12  * keith_millerjoined
13:25:23  * caridyjoined
13:30:11  * caridyquit (Ping timeout: 256 seconds)
13:48:39  <jmdyck>littledan: ?
14:05:45  * caridyjoined
14:10:05  * caridyquit (Ping timeout: 240 seconds)
14:10:57  <littledan>jmdyck: What is the question?
14:11:22  <jmdyck>hi, was just looking at https://github.com/tc39/ecma262/pull/1102#issuecomment-366656468
14:11:55  <littledan>jschoi: I share the concern from other commenters about adding another arrow type adding complexity and confusion
14:12:16  <littledan>jmdyck: Yeah, I'd love to hear what you think of that
14:12:42  <jmdyck>re "I think that's what the current patch does." It looks to me like the current *spec* handles all three bullets.
14:12:54  <jmdyck>the current spec does something different
14:13:09  <jmdyck>wah, no, the current *patch* does something different
14:14:33  <jschoi>littledan: Noted, thanks. I’ll not actually add it to the draft specification; it’ll be confined to an appendix in the explainer as a potential add on.
14:15:18  <jschoi>An add-on to be considered later, that is.
14:23:02  * caridyjoined
14:24:38  <jmdyck>littledan: also, i was thrown a bit by "The grammar here only is relevant on non-Unicode RegExps." I thought you were talking about the whole Appendix B grammar, but now I think you're only talking about the QuantifiedAssertion production (which is indeed only 'accessible' in non-unicode mode).
14:25:06  <littledan>heh! Right
14:25:47  <littledan>edited comment for clarity
14:27:16  * caridyquit (Ping timeout: 248 seconds)
14:27:24  <jmdyck>well, you changed it to the B.1.4 grammar, but that's still too large to say that it's only relevant on non-unicode regexps
14:27:38  <jmdyck>or, i suppose it depends on what you mean by 'relevant'
14:30:27  <jmdyck>the spec requires web browsers to use the B.1.4 grammar in both u and non-u mode, so it's relevant in that sense.
14:34:45  <jmdyck>but it also claims that it doesn't extend the main-body syntax+semantics in u mode.
14:47:32  <jmdyck>so a browser would supposedly be okay, when implementing u mode, to stick with main-body syntax+semantics.
14:47:51  <jmdyck>So there's a sense in which it's relevant and a sense in which it isn't.
14:49:04  <jmdyck>littledan: anyhow, re puzzling over [?U] parameters, can you give an example?
14:59:50  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:05:09  <jmdyck>hm, maybe I understand what you mean now.
15:05:45  * keith_millerjoined
15:15:07  <jmdyck>You're thinking that B.1.4 grammar is 'invoked' only when U is unset. While you might be able to arrange an implementation that way, that's not what the spec is doing. Rather, B.1.4 provides productions that wholly *replace* the corresponding productions from 21.2.1, and thus they have to 'work' for both ~U and +U.
15:22:39  * caridyjoined
15:27:05  * caridyquit (Ping timeout: 240 seconds)
15:38:10  <littledan>jmdyck: Oh, that is what I was thinking
15:38:19  <littledan>I guess this explains the [U] flags
15:39:00  <littledan>so it's like, the grammar might as well only be invoked for [~U], but it's also invoked for [U], just having no effect
15:39:36  <jmdyck>hm, don't think so.
15:41:20  <jmdyck>I'd say the B.1.4 is 'invoked' (in a browser, of course) for both +U and ~U.
15:43:15  <jmdyck>(with a by-the-way that when it's invoked for +U, the syntax you get is the same as if you'd invoked 21.2.1 for +U)
15:45:19  <jmdyck>(or: ... the same as if a non-appendix-B implementation invoked 21.2.1 for +U)
15:50:43  <jmdyck>I suppose it depends on what you meant by "having no effect". If you mean "having no effect other than what 21.2.1 would have given you", then yeah, but that's still an effect.
16:21:50  * gibson042joined
16:40:59  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:41:45  <jschoi>Static errors can say, “It is a Syntax Error if parseNode is not covered by SupplementalGrammarProduction”. But can they say, “It is a Syntax Error if parseNode *is* covered by SupplementalGrammarProduction”?
16:43:29  <jschoi>In an early error’s algorithm, I mean.
16:48:16  <jmdyck>That "is not covered by" should be "is not covering". But yeah, an early error rule can say "is covering".
16:50:23  <jmdyck>https://tc39.github.io/ecma262/#sec-for-in-and-for-of-statements-static-semantics-early-errors uses "is covering". It's not in a bullet, but it is part of the early errors machinery.
16:51:30  * caridyjoined
17:28:53  <jschoi>jmdyck: Thanks!
17:38:48  <ljharb>jschoi: i haven't changed my mind about the severity of the footgun; but i've probably changed my mind that there was a better-yet-tenable alternative.
17:40:09  * keith_millerjoined
17:46:27  <jschoi>ljharb: Thanks, that clarifies it.
17:52:08  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:04:33  * keith_millerjoined
18:52:25  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:57:17  * keith_millerjoined
18:59:03  * jwaldenjoined
19:22:56  * gibson042quit (Ping timeout: 276 seconds)
20:18:15  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:30:38  * keith_millerjoined
20:32:07  * bradleymeckjoined
20:34:53  * bradleymeckquit (Client Quit)
20:45:11  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:49:30  * gskachkovjoined
20:49:57  * keith_millerjoined
21:00:30  * caridyquit (Remote host closed the connection)
21:28:56  * gskachkovquit (Read error: Connection reset by peer)
21:55:03  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:03:02  * keith_millerjoined