| 02:46 | <devsnek> | CreateDynamicFunction says stuff like |
| 02:46 | <devsnek> | "if kind is generator, let parameterGoal be FormalParameters[+Yield, ~Await]" |
| 02:47 | <devsnek> | but then later down it says "throw a syntax error if kind is generator and FormalParameters contains YieldExpression" |
| 02:47 | <devsnek> | why not just set parameterGoal to [~Yield, ~Await] |
| 02:53 | <devsnek> | i wonder if this entire thing could be shortened by cutting out all this manual parsing and just specifying it to evaluate sourceString that is defined way at the bottom |
| 03:15 | <jmdyck> | using [~Yield] would have allowed 'yield' as an identifier, which would be confusing. |
| 03:16 | <devsnek> | interesting |
| 03:16 | <devsnek> | ok on a separate topic |
| 03:17 | <devsnek> | is it fair to imagine that UTF16EncodeString and UTF16DecodeString convert between some abstract host string form and js string values |
| 03:21 | <jmdyck> | I don't think so. |
| 03:22 | <devsnek> | hmm |
| 03:23 | <devsnek> | they generally seem to be used when passing strings back and forth between host parsing and js |
| 03:23 | <jmdyck> | The spec assumes that the host understands ES String values. |
| 03:23 | <devsnek> | well yeah but like |
| 03:23 | <devsnek> | "let x be the result of ! UTF16Decode(string)" |
| 03:23 | <devsnek> | er |
| 03:24 | <jmdyck> | if the host has an abstract string form, conversion between that and ES String values is completely hidden from spec-land. |
| 03:24 | <devsnek> | "let x be the result of parsing ! UTF16Decode(string)" |
| 03:25 | <jmdyck> | Yup, those ao's are mostly used for converting between *source text* and ES Strings. |
| 05:55 | <Bakkot> | devsnek: UTF16Encode UTF16DecodeString should be thought of as converting between _Unicode_ strings (more precisely, sequences of codepoints) and ES strings |
| 05:56 | <devsnek> | i'm just trying to figure out if i really need to store source text on functions as an array of code point records |
| 05:56 | <Bakkot> | "Unicode strings" and "host strings" are not typically the same, especially given how shoddy unicode support is in most languages |
| 05:56 | <Bakkot> | ah: no |
| 05:56 | <devsnek> | i mean i know technically i don't have to |
| 05:56 | <devsnek> | but the spec seems to want me to |
| 05:57 | <Bakkot> | that's just because it's a nice formalism, not implementation advice |
| 05:57 | <Bakkot> | here, this is why: https://github.com/tc39/ecma262/pull/1547#issuecomment-581005549 |
| 05:58 | <devsnek> | i see |
| 14:43 | <srl295> | devsnek: it should still be a string.. Bakkot : not sure what you mean about host strings, are you talking about non-unicode host encodings? |
| 14:44 | <devsnek> | srl295: it's a List |
| 14:48 | <srl295> | devsnek: even in implementation? |
| 14:48 | <devsnek> | not in implementation |
| 14:48 | <devsnek> | hopefully |
| 14:48 | <devsnek> | but in spec |
| 15:00 | <srl295> | ^ OK, thx |
| 15:58 | <gibson042> | [[SourceText]] is a sequence of code points to match lexical source text, but String values can represent those per https://tc39.es/ecma262/#sec-ecmascript-language-types-string-type . There's an edge case of "leading surrogate code _point_ followed by trailing surrogate code _point_" (which would be interpreted as a surrogate pair for a single code unit), but I don't see a way to ever encounter that because it cannot be represented i |
| 16:00 | <gibson042> | s/surrogate pair for a single code unit/surrogate pair for a single code point/ |
| 16:24 | <devsnek> | it would be kinda cool if `{ ...x, y }` binding created x as a copy of whatever was being matched |
| 16:25 | <devsnek> | sort of the reverse of a `{ ...x, y }` expression |
| 16:29 | <Bakkot> | devsnek: ... doesn't it? |
| 16:29 | <devsnek> | no |
| 16:29 | <devsnek> | it's not valid syntax |
| 16:30 | <devsnek> | rest binding element is only valid at the end |
| 16:30 | <Bakkot> | ah, sorry, yes |
| 16:30 | <devsnek> | at some point maybe i'll go check if it was left as future work or explicitly not wanted |
| 16:32 | <Bakkot> | there have been proposals that `[ ...x, y] = [1, 2, 3]` give you `x = [1, 2]; y = [3]` |
| 16:32 | <Bakkot> | which seems like a different thing than what you're proposing |
| 16:33 | <devsnek> | i wouldn't want to get into array bindings |
| 16:34 | <devsnek> | array bindings are tricky because the order of the bindings has to match up with meaningful behaviour about the order of the elements |
| 16:34 | <devsnek> | don't have to worry about that with object bindings |
| 16:52 | <devsnek> | i think the spec is missing the definition for the evaluation of AsyncGeneratorDeclaration |
| 16:56 | <devsnek> | oh nvm its grouped in as HoistableDeclaration |
| 16:57 | <annevk> | ljharb: FWIW, https://github.com/tc39/ecma262/issues/1524#issuecomment-613554699 the plan is not particularly detailed and shu suggested it did not include changing all existing occurrences of host in a #whatwg discussion |
| 16:59 | <ljharb> | annevk: ah k, what we'd discussed was changing all prose instances of host to implementation; i don't recall for sure, but we probably also discussed not changing hook names with "Host", to avoid churn |
| 17:01 | <annevk> | ljharb: again, not what shu told me in https://freenode.logbot.info/whatwg/20200409#c3606032 |
| 17:02 | <shu> | the context for host->implementation per the last plan was particularly for the phrase "host-defined" vs "implementation-defined" and "implementation-dependent" |
| 17:02 | <shu> | not the bare word "host" vs "implementation" |
| 17:02 | <ljharb> | ah k |
| 17:02 | <ljharb> | ty for clarifying |
| 17:03 | <shu> | but there was enough unhappiness around that plan that i plan to bring it up again in the editor call anyway |
| 17:04 | <Bakkot> | annevk: re https://github.com/tc39/ecma262/issues/1524#issuecomment-613269942: would you also be OK with providing overridable abstract operations only for those things for which we are aware of some host which wants to specify the behavior? |
| 17:05 | <Bakkot> | because specifying a bunch of host ops which no one has any interest in using is a fair bit of work for no obvious benefit |
| 17:05 | <annevk> | Bakkot: at that point your are making a distinction some people think there is not |
| 17:05 | <annevk> | Bakkot: and I'd argue you're being inconsistent |
| 17:06 | <annevk> | Bakkot: if you don't want to acknowledge hosts and live in your vacuum, then don't acknowledge them (while still making things) |
| 17:06 | <annevk> | work* |
| 17:07 | <annevk> | if you want to be pragmatic, embrace all the text that acknowledges hosts |
| 17:07 | <Bakkot> | I agree it is mildly inconsistent, but the inconsistency does not particularly bother me. we're defining an API; only putting the things for which there is some consumer into the API is fine. |
| 17:07 | <annevk> | it bothers me because people keep saying a Host hook is equivalent to NaN stuff |
| 17:08 | <srl295> | Bakkot: for my understanding, what's the 'host' situation you are referring to? |
| 17:08 | <Bakkot> | srl295 context is mostly in https://github.com/tc39/ecma262/issues/1524 |
| 17:08 | <Bakkot> | annevk: I don't understand what you mean by that; say more? |
| 17:10 | <annevk> | Bakkot: I think if you want to say that implementation and host are the same, you ought to actually remove the distinction and not only offer it to those who can read between the lines |
| 17:11 | <srl295> | Bakkot: Right, but you referred specifically to Unicode support on the host, which seems to be AWB's footnote 1, is that what you mean? |
| 17:12 | <Bakkot> | srl295 the Unicode conversation was totally unrelated to this conversation |
| 17:13 | <Bakkot> | annevk how is "change everything to say implementation defined, keep hooks in place for places where they are useful" not that? |
| 17:13 | <Bakkot> | annevk I guess mostly I fundamentally do not udnerstand what distinction you think there is |
| 17:14 | <srl295> | Bakkot: OK. carry on then… |
| 17:14 | <Bakkot> | if the distinction is "suggest to implementors that there's another place to look for restrictions on something ECMA-262 does not specify", it seems like that proposal accomplishes it perfectly |
| 17:14 | <Bakkot> | if the distinction in your mind is something other than that, then I don't know what it is |
| 17:17 | <annevk> | What I'm saying is that implementation-defined with hook = host hook and implementation-defined without hook is implementation-defined, except now you made it more opaque. |
| 17:17 | <annevk> | So at that I'd rather have everything be a hook and let the host^Wimplementation decide who defines what |
| 17:17 | <Bakkot> | made it more opaque than... what? that's the current state of the specification. |
| 17:18 | <annevk> | Bakkot: the current specification talks about hosts a bunch |
| 17:20 | <Bakkot> | annevk in host hooks, yes. outside of host hooks, not really? |
| 17:20 | <Bakkot> | not in anything normative, that I can see, except for properties of the global object and "the host environment's current locale" |
| 17:29 | <annevk> | Bakkot: I'm including the non-normative material, that's somewhat relevant for this discussion I think |
| 17:30 | <Bakkot> | of the 166 usages of "host" in the spec, the only ones which are not describing host hooks, locale, or the global object (or values otherwise made available) are: |
| 17:30 | <Bakkot> | 1. the [[HostDefined]] slot on realm, script, and module records |
| 17:31 | <Bakkot> | 2. the Note about enumerate object properties not requiring a specific algorithm (which should definitely be changed to "host") |
| 17:31 | <Bakkot> | 3. the `hostDefined` argument to ParseScript (which populates [[HostDefined]], and which is basically a host hook just in the other direction) |
| 17:31 | <Bakkot> | 4. the prose in the example of cyclic module record graphs, which is about hosts calling ES abstract methods - again basically a host hook in the other direction |
| 17:32 | <Bakkot> | 5. locale |
| 17:32 | <annevk> | "ECMAScript is an object-oriented programming language for performing computations and manipulating computational objects within a host environment." |
| 17:33 | <Bakkot> | 6. "host-defined exceptions that can occur anywhere such as out-of-memory", which could be changed to "implementation" |
| 17:33 | <Bakkot> | 7. host-synchronizes-with, which is basically a host hook |
| 17:33 | <Bakkot> | 8. annex b's "when the ECMAScript host is a web browser" |
| 17:33 | <Bakkot> | that's the list. |
| 17:34 | <annevk> | It's a list for sure :-) |
| 17:34 | <Bakkot> | annevk that paragraph is very clearly (to me) about providing the global object or values otherwise made available and integration with host hooks, and nothing else. |
| 17:35 | <Bakkot> | I agree that 2 and 6 should change "host" to "implementation" |
| 17:35 | <Bakkot> | but other than that, how does this... not already give you what you want? |
| 17:36 | <Bakkot> | with the exception of 2 and 6, we use "implementation-defined" only for things which HTML and other hosts do not specify, to my knowledge |
| 17:36 | <Bakkot> | so what distinction do you want drawn that is not currently drawn? |
| 17:37 | <Bakkot> | specifically, that is not currently drawn by the dichotomy between things which are specified as host hooks and things which are specified to be implementation-defined? |
| 17:37 | <annevk> | Bakkot: it sounds like you might not have followed the issue where there's a bunch of talk about removing all instances of "host" as if it's a bad word |
| 17:37 | <Bakkot> | annevk I have read and commented on that issue |
| 17:37 | <annevk> | Then I'm not sure what to tell you |
| 17:38 | <Bakkot> | annevk _you opened that issue_ |
| 17:38 | <Bakkot> | annevk I am trying to figure out _what you want_ |
| 17:38 | <Bakkot> | I do not particularly care about AWB's theoretical purity concerns |
| 17:38 | <annevk> | I want the draft to go further in what it already does |
| 17:38 | <Bakkot> | in what way? |
| 17:38 | <Bakkot> | what change to the list above, or to the usages of "implementation-defined", are you looking for? |
| 17:39 | <annevk> | Distinguishing hosts and implementations, we might well agree 🙂 |
| 17:39 | <Bakkot> | What distinction other than the one already there are you looking for? |
| 17:40 | <Bakkot> | Do you just want it to say "a host is the name for the thing which provides additional ambiently available values and defines the host hooks, an implementation the name for the thing which does everything else"? |
| 17:41 | <Bakkot> | or are you actually looking for some changes to our existing usages of "implementation" and "host"? and, if so, what changes? |
| 17:42 | <annevk> | Bakkot: I think the second paragraph in https://github.com/tc39/ecma262/issues/1524#issuecomment-600816056 is what would be ideal |
| 17:43 | <annevk> | Bakkot: provide host hooks and expectations around it and also provide a default host implementation (perhaps that can leave everything implementation-defined, but I'm not sure that would quite work since you have to setup agent clusters, agents, and realms in a certain order for things to make sense) |
| 17:43 | <ljharb> | I'm still not clear on why the "not html spec" should be distinguishing between "things individual html spec implementations can do" and "things only the html spec can do" |
| 17:44 | <ljharb> | the place to understand what all browsers, versus individual browsers, must do is the html spec. what am i missing about what you want to be in 262? |
| 17:44 | <Bakkot> | annevk two things: 1.) now that I've actually read through every usage of "host" and "implementation" in the spec, I don't actually think the two things are not distinguished |
| 17:44 | <annevk> | Bakkot: I agree with you on the status quo |
| 17:45 | <Bakkot> | specifically, they are distinguished by, we use host hooks + the global object for things HTML is expected to specify, and "implementation-defined" for everything else |
| 17:45 | <Bakkot> | and 2.) in what way does the "put links to the HTML spec where things are specified by the HTML spec" proposal not satisfy that goal? |
| 17:45 | <annevk> | Bakkot: well no, e.g. InitializeHostDefinedRealm says implementation-defined a bunch of times which is false |
| 17:45 | <annevk> | Bakkot: it's also a very bad hook |
| 17:46 | <annevk> | for any reasonable host |
| 17:46 | <annevk> | which ECMA-262 would realize if it tried to define a host pretty quickly |
| 17:46 | <ljharb> | do you think `InitializeHostDefinedRealm` should be more constrained? |
| 17:47 | <Bakkot> | annevk I am happy to change "implementation-defined" to "host-defined" in that abstract operation. |
| 17:47 | <Bakkot> | annevk are there other changes you would like to see? |
| 17:47 | <annevk> | ljharb: possibly, it should probably take parameters of sorts, it's very much unclear how to hold it |
| 17:48 | <annevk> | I think a good exercise would be for ECMA-262 editors to define a minimal host with the same rigor as ECMA-262 is defined and see where it breaks down |
| 17:48 | <annevk> | Aside from the obvious fail points such as agents there are others |
| 17:53 | <Bakkot> | annevk sure, I am willing to believe there are places things are underspecified or lack arguments. but other than "fix your bugs", which, sure, we are doing our best", I still do not know what actual changes you would like to see as a result of 1524 |
| 17:54 | <Bakkot> | except I guess changing `InitializeHostDefinedRealm` to use `host-defined` instead of `implementation-defined`? |
| 17:54 | <Bakkot> | (or adding explicit host hooks to it instead of saying implementation-defined, or whatever) |
| 17:59 | <shu> | annevk: concretely there *are* things we disagree about for what's an implementation's purview vs what's a host's purview |
| 17:59 | <shu> | NaN is (i hope) uncontroversial, but we didn't see reason to preclude exponentiation from constrained by an upstream spec, for instance |
| 18:00 | <Bakkot> | yeah if some upstream spec asks for it I would happily add a host hook which says how exponentiation works more precisely |
| 18:04 | <devsnek> | PerformEval calls GetThisEnvironment |
| 18:04 | <devsnek> | if it was a direct eval, the running execution context was created by the builtin function [[Call]] method |
| 18:04 | <devsnek> | such an execution context has no LexicalEnvironment |
| 18:05 | <devsnek> | and then step 2.a fails |
| 18:05 | <devsnek> | 2.a of GetThisEnvironment |
| 18:05 | <devsnek> | does that sound right |
| 18:08 | <shu> | there's a special case for direct eval in 12.3.6.1, step 6 |
| 18:09 | <shu> | don't think it goes through the built-in function [[Call]] |
| 18:09 | <shu> | but maybe you still found a bug for indirect eval? not sure without digging deeper right now |
| 18:10 | <devsnek> | oh maybe i meant indirect |
| 18:10 | <devsnek> | the one where it actually calls %eval% |
| 18:11 | <devsnek> | i guess that's indirect |
| 18:18 | <Bakkot> | yeah, looks like that should be changed so that it's only performed for direct evals |
| 18:19 | <devsnek> | well it needs to be performed in either case right |
| 18:19 | <Bakkot> | no |
| 18:19 | <Bakkot> | the GetThisEnvironment call is just there to see if you get to do super calls or whatever |
| 18:19 | <Bakkot> | which you never get to do for indirect evals |
| 18:19 | <devsnek> | where does it say you can't |
| 18:19 | <Bakkot> | well, in principle, here |
| 18:19 | <Bakkot> | but it's bugged |
| 18:20 | <Bakkot> | but, like, try it and see |
| 18:20 | <devsnek> | oh you mean implementations don't allow it |
| 18:20 | <Bakkot> | yeah |
| 18:20 | <Bakkot> | and are not supposed to |
| 18:20 | <devsnek> | got it |
| 18:21 | <Bakkot> | (but the "not supposed to" is meant to be specified in PerformEval, and it's buggy, as you observe) |
| 18:21 | <devsnek> | https://gc.gy/54593505.png |
| 18:22 | <devsnek> | is the empty step implicit |
| 18:23 | <shu> | might be editorially clearer to reorder most of those steps |
| 18:24 | <shu> | unconditionally initialize in{Function,Method,DerivedConstructor} to false |
| 18:24 | <shu> | then subsume the current steps 5 and 6 under "if direct" |
| 18:24 | <devsnek> | seems legit |
| 18:27 | <devsnek> | https://github.com/tc39/ecma262/pull/1949 |
| 18:55 | <Bakkot> | re: "is the empty step implicit": I would say no |
| 19:16 | <jridgewell> | Back to devsnek's `{ ...x, y }` syntax |
| 19:16 | <devsnek> | 👀 |
| 19:16 | <jridgewell> | We could add that, and it wouldn't be conflicting with the `[ ...x, y ]` syntax |
| 19:17 | <jridgewell> | Because `{ y, ...x }` already does what `[ ...x, y ]` is intending to do. |
| 19:17 | <jridgewell> | The patterns are like reverses of each other. |
| 19:18 | <jridgewell> | `x` would contain everything except the `y` in both cases |
| 19:19 | <jridgewell> | `[ ...x, y ]` would be different than ` { ...x, y }` |
| 19:20 | <jridgewell> | But if we tried to make the object rest match the array rest, then `{ ...x, y }` would be equivalent to `{ y, ...x }` |
| 19:31 | <ljharb> | what syntax do you mean? |
| 19:32 | <devsnek> | ljharb: <+devsnek> it would be kinda cool if `{ ...x, y }` binding created x as a copy of whatever was being matched |
| 19:33 | <ljharb> | in pattern matching? |
| 19:33 | <ljharb> | or like in general |
| 19:33 | <devsnek> | yeah |
| 19:33 | <devsnek> | in bindings |
| 19:33 | <ljharb> | isn't that https://github.com/zkat/proposal-as-patterns ? |
| 19:34 | <devsnek> | no it would just be an extension of current binding syntax |
| 19:34 | <devsnek> | oh is that what that is |
| 19:34 | <ljharb> | `{ ...x, y }` tho would be super confusing if it wasn't the same as `{ y, ...x }` |
| 19:34 | <ljharb> | yes |
| 19:34 | <devsnek> | neat |
| 19:34 | <devsnek> | `{ y, ...x }` and `{ ...x, y }` aren't the same as object literals |
| 19:35 | <devsnek> | dunno why bindings would have to be |
| 19:36 | <ljharb> | that's because the latter is an error |
| 19:36 | <ljharb> | if a non-error, i'd expect them to be the same |
| 19:36 | <ljharb> | oh in object literals |
| 19:36 | <devsnek> | neither of those are errors in object literals |
| 19:36 | <ljharb> | they're the same if `x` doesn't have `y` :-p |
| 19:36 | <devsnek> | ok but |
| 19:36 | <devsnek> | they aren't the same |
| 19:37 | <devsnek> | the order matters |
| 19:37 | <Bakkot> | yeah but that is very rarely a difference which matters |
| 19:37 | <Bakkot> | (and is also obviously the difference, from the syntax) |
| 19:37 | <ljharb> | and conceptually they're doing the same kinds of things |
| 19:37 | <Bakkot> | which properties there are matters a lot more |
| 19:38 | <devsnek> | its the same with bindings |
| 19:38 | <devsnek> | `{ y, ...x }` obj without y `{ ...x, y }` obj with y |
| 19:40 | <Bakkot> | I don't think that is obvious |
| 19:40 | <ljharb> | it's not obvious to me at all |
| 19:40 | <Bakkot> | also it would be really confusing if we had the `let [...x, y]` syntax mean the thing people have asked for it to mean |
| 19:40 | <devsnek> | i don't see how its any more or less obvious than the object literal |
| 19:42 | <ljharb> | because in the curly braces, the three dots syntax with x either means "grab everything into x except the other things mentioned" or "pull everything from x into this new object". having it mean "grab everything, even the other things mentioned" would be wildly confusing to me |
| 19:42 | <ljharb> | like `const { …x } = obj; const { y } = obj` seems *way* clearer to me than your suggestion |
| 19:43 | <devsnek> | why is it confusing for bindings to be unordered but for literals to be ordered |
| 19:43 | <devsnek> | er |
| 19:43 | <devsnek> | why is it confusing for bindings to be ordered when it isn't for literals |
| 19:43 | <ljharb> | in bindings, it's pulling things out of the object. in literals, it's smooshing things into it |
| 19:44 | <devsnek> | right |
| 19:44 | <ljharb> | when pulling things out, it's confusing for "y" to be pulled twice if it's only mentioned once |
| 19:44 | <ljharb> | iow, object destructuring currently only pulls each value once ever, or zero times |
| 19:44 | <devsnek> | when smooshing things in its confusing for y to be smooshed in twice if its only mentioned once? |
| 19:44 | <ljharb> | (unless you repeat it, actually, now that i think of it) |
| 19:45 | <ljharb> | i mean, `y` itself would only go in once |
| 19:45 | <ljharb> | a spreaded object's `y` would also go in, sure |
| 19:45 | <devsnek> | expression goes from 2y to 1y |
| 19:45 | <devsnek> | binding goes from 1y to 2y |
| 19:45 | <devsnek> | it's a symmetry |
| 19:46 | <ljharb> | not sure i get what you mean |
| 19:46 | <ljharb> | `const obj = { …x, y }` only has one `y` on `obj` |
| 19:46 | <ljharb> | `const { y, …x } = obj` only has one `y` binding |
| 19:47 | <devsnek> | `({ ...x, y } = { ...x, y })` |
| 19:47 | <ljharb> | i do see how in the former example, `x.y` and `y` might both exist but would still get smooshed into one `y` |
| 19:47 | <devsnek> | this symmetry |
| 19:47 | <ljharb> | right but that wouldn't be symmetrical |
| 19:47 | <ljharb> | because the original `x.y` value would be lost |
| 19:47 | <devsnek> | the shape |
| 19:47 | <devsnek> | not the identity of the values |
| 19:47 | <ljharb> | `x` would have the same shape as the RHS, sure |
| 19:48 | <ljharb> | but the point of destructuring is to take apart the shape |
| 19:48 | <ljharb> | to de structure it |
| 19:48 | <devsnek> | sort of? |
| 19:48 | <devsnek> | people use it for cloning too |
| 19:49 | <ljharb> | sure but that's not the point of the feature |
| 19:49 | <ljharb> | people use JSON for cloning, doesn't mean "cloning" is relevant to json |
| 19:49 | <devsnek> | i mean people use it to perform the operation it performs |
| 19:50 | <devsnek> | how that operation was meant to be used is kind of irrelevant |
| 19:50 | <ljharb> | i don't agree with that |
| 19:50 | <Bakkot> | devsnek: `[...x, y] = [...a, b]` is not syntax which currently exists, bu to me it has one obvious meaning: `x` gets `a`, `y` gets `b`. |
| 19:50 | <ljharb> | ^ me too |
| 19:50 | <Bakkot> | devsnek: the same intuition tells me that `{...x, y} = {...a, b}` has the meaning `x` gets `a`, `y` gets `b`. |
| 19:51 | <devsnek> | right array literals have an coupling between the order of elements and the order of bindings |
| 19:51 | <devsnek> | you mean `{...x, b}`? |
| 19:51 | <Bakkot> | ah, sorry, yes |
| 19:51 | <Bakkot> | should've named the properties instead of using shorthand |
| 19:52 | <Bakkot> | `{...x, p: y} = {...a, p: b}` has the meaning `x` gets `a`, `y` gets `b` |
| 19:53 | <devsnek> | maybe its better if we leave it as a syntax error |
| 19:53 | <devsnek> | because i don't agree with that |
| 19:56 | <Bakkot> | the way I would put it is, `...` on the LHS means to me "every other thing", not "every other thing to the left of `...`", even though these are currently equivalent |
| 20:03 | <rkirsling> | +1 |
| 22:38 | <devsnek> | jridgewell: why are the logical assignment operators in their own LogicalAssignmentOperator production |
| 22:42 | <rkirsling> | just for proposal readability |
| 22:42 | <rkirsling> | (see the note at the very top) |
| 22:43 | <rkirsling> | oh you mean operator |
| 22:43 | <devsnek> | hm |
| 22:43 | <devsnek> | i guess for the same reason |
| 22:44 | <rkirsling> | we mentioned needing to rename that to ShortCircuitOperator prior to merge but I thought that part was needed to avoid some AssignmentOperator implications |
| 22:44 | <rkirsling> | lemme check |
| 22:44 | <rkirsling> | *ShortCircuitAssignmentOperator, I mean |
| 22:45 | <rkirsling> | er yeah that's exactly it |
| 22:45 | <rkirsling> | there's only one RS for AssignmentExpression:LeftHandSideExpressionAssignmentOperatorAssignmentExpression |
| 22:45 | <rkirsling> | grr AssignmentExpression : LeftHandSideExpression AssignmentOperator AssignmentExpression even |
| 22:45 | <ljharb> | altho jridgewell, with the newest ecmarkup/grammarkdown, you might no longer need to mention it as a separate productiopn |
| 22:46 | <ljharb> | like, the inline `<ins>` might Just Work |
| 22:46 | <rkirsling> | but each short circuit assignment op has its own RS case |
| 22:47 | <devsnek> | so its going to be its own production |
| 22:47 | <devsnek> | not an AssignmentExpression |
| 22:47 | <rkirsling> | I mean it has to not be an AssignmentExpression at the very least |
| 22:48 | <rkirsling> | er |
| 22:48 | <rkirsling> | dammit |
| 22:48 | <rkirsling> | AssignmentOperator |
| 22:48 | <devsnek> | why |
| 22:48 | <rkirsling> | it *is* an AssignmentExpression |
| 23:18 | <devsnek> | can we rename NameSpaceImport to NamespaceImport |
| 23:19 | <ljharb> | yes please |
| 23:19 | <rkirsling> | lol that is a really irritating capitalization |
| 23:19 | <Bakkot> | import { mars } from space; |
| 23:19 | <rkirsling> | welcome to the Name Space |
| 23:20 | <devsnek> | :notlikethis: |
| 23:22 | <rkirsling> | it'd make sense in the sentence "`foo = 0` and `fox = {...}` are close in name space but not in value space" |
| 23:48 | <shu> | not as annoying as NamespaceImPort |
| 23:49 | <rkirsling> | ow |
| 23:49 | <rkirsling> | it hurts |
| 23:51 | <ljharb> | it's a good port |
| 23:54 | <rkirsling> | I mean if it's German then I'm okay with it |
| 23:54 | <rkirsling> | Namespace in dem Port |
