| 01:14 | <devsnek> | i'm wondering if there might be a way to specify a method for sync and async iterator prototypes at the same time |
| 01:14 | <devsnek> | sort of got this thing going https://gc.gy/55914273.png |
| 05:14 | <devsnek> | ljharb: is there some issue with netlify? |
| 05:16 | <ljharb> | devsnek: yep, they won't give us a free account without compulsory advertising, and they'll shut us down after today |
| 05:16 | <devsnek> | oh that's unfortunate |
| 05:16 | <ljharb> | devsnek: and any service that forces "free" accounts to advertise isn't free, and isn't something i'll be recommending to anyone ever again |
| 05:16 | <ljharb> | otherwise it worked great tho |
| 05:17 | <devsnek> | yeah that's kind of a shame |
| 05:24 | <bakkot> | it is free in the sense students care about, just not so much in the sense engineers trying to avoid an expense report care about |
| 05:25 | <ljharb> | also not free in the sense that the ecosystem they're hoping to lure, open source, cares about. |
| 05:26 | <bakkot> | I dunno, that's definitely the sense I cared about when I was publishing open source stuff in college |
| 20:35 | <devsnek> | has anyone ever come across js code that didn't evaluate to what they expected in when entered in a repl |
| 20:35 | <devsnek> | like how `while (true) { 5; break; }` evaluates to 5 |
| 20:35 | <devsnek> | although that one doesn't seem too surprising |
| 20:40 | <bakkot> | devsnek: https://github.com/tc39/proposal-do-expressions/issues/21 |
| 20:40 | <devsnek> | well yes i was thinking about do expressions |
| 20:41 | <devsnek> | i don't think people are generally very surprised by the results in repl |
| 20:41 | <devsnek> | at least that is my theory |
| 20:42 | <rkirsling> | wait whoa |
| 20:42 | <rkirsling> | oh maybe this did come up in the context of do exprs and I let it go past me but |
| 20:43 | <rkirsling> | I didn't know `eval('while (true) { 5; break; }')` would not return undefined |
| 20:43 | <devsnek> | lol |
| 20:43 | <devsnek> | yeah break and continue completions have an ~empty~ [[Value]] |
| 20:43 | <devsnek> | so it gets replaced by the value of the last item in the statement list |
| 20:44 | <rkirsling> | mind blown |
| 20:44 | <rkirsling> | I thought completion values were purely spec-internal up 'til now |
| 20:44 | <devsnek> | i mean they kind of are |
| 20:44 | <devsnek> | in terms of implementation you have a stack or accumulator |
| 20:45 | <devsnek> | and the last thing that modified the stack/accumulator is the `5` |
| 20:45 | <rkirsling> | (which is kind of silly because I've definitely looked at the thread bakkot linked; clearly something failed to click before...) |
| 20:46 | <rkirsling> | isn't that specific to SM and V8 respectively though |
| 20:46 | <devsnek> | wdym |
| 20:47 | <rkirsling> | SM bytecode and V8 bytecode are centered around stack and accumulator respectively but this isn't so for JSC |
| 20:47 | <devsnek> | oh i see |
| 20:47 | <devsnek> | registers too |
| 20:47 | <rkirsling> | yeah |
| 20:47 | <devsnek> | i just meant |
| 20:48 | <devsnek> | you have some place where you're expecting a value |
| 20:48 | <devsnek> | and break doesn't touch it |
| 20:49 | <devsnek> | it is a shame that if statements return undefined instead of empty though |
| 20:49 | <bakkot> | that was changed in ES6 actually |
| 20:49 | <devsnek> | yeah i know |
| 20:49 | <devsnek> | well anyway i was just thinking |
| 20:49 | <TabAtkins> | devsnek: {}+[] was the triadtional answer, but repls might have fixed that now |
| 20:50 | <ljharb> | i assume we could get browsers on board with changing a number of these things as part of the do expressions proposal, if we all agreed the change was good |
| 20:50 | <TabAtkins> | nope, still there |
| 20:50 | <TabAtkins> | in chrome, at least |
| 20:50 | <bakkot> | I think that completion values no longer have any cases where something either is or is not empty depending on runtime values |
| 20:50 | <bakkot> | which I am happy about |
| 20:50 | <devsnek> | TabAtkins: in the repl proposal, lookahead = { is parsed as an object literal |
| 20:51 | <devsnek> | but anyway my idea was that people generally don't seem bamboozled by how the repl behaves (block vs object literal aside) |
| 20:52 | <devsnek> | TabAtkins: interestingly in the node repl it eagerly tries to wrap the input in (), so it parses as object literal |
| 20:52 | <TabAtkins> | Yeah, that's the behavior I'd naively expect. |
| 20:52 | <TabAtkins> | RAther than {}+[] being a block followed by +[] |
| 20:53 | <TabAtkins> | But yeah, that's literally the only thing I've been confused about |
| 20:53 | <devsnek> | we should've used {||} for blocks /s |
| 20:54 | <bakkot> | should've used `<>` |
| 20:54 | <bakkot> | and had the token between key and value be `=` |
| 20:54 | <bakkot> | so it would look like HTML |
| 20:54 | <devsnek> | lol |
| 20:55 | <devsnek> | interestingly the completion reform makes js more like rust |
| 20:56 | <devsnek> | you have to do `if (a) { b } else { c }` instead of `c; if (a) { b }` |
| 20:57 | <ljharb> | or `a ? b : c`? |
| 20:57 | <ljharb> | or are b and c standins for a statement list |
| 20:57 | <devsnek> | yea |
| 20:58 | <ljharb> | i'd still probably do that with two do expressions on both sides of the ternary :-p |
| 20:58 | <devsnek> | and that is okay |
| 20:58 | <ljharb> | ty for validating me <3 |
| 20:58 | <devsnek> | so do expressions for stage 4, any objections? |
| 20:58 | <ljharb> | ship it, it makes pattern matching infinitely easier |
| 21:01 | <devsnek> | oh btw i was trying to work out how to make iterators specified in a less weird way |
| 21:01 | <devsnek> | came up with this so far |
| 21:01 | <devsnek> | https://gc.gy/55985455.png https://gc.gy/55985482.png |
| 21:02 | <devsnek> | those wrapped iterator things are macros which call the appropriate sync or async methods and handle awaiting |
| 21:02 | <ljharb> | devsnek: i think the throw and return methods need `Await` in the async version |
| 21:03 | <devsnek> | oh yeah those need lots of changes |
| 21:03 | <ljharb> | ie, the same thing shu had to do in Atomics.wait vs Atomics.waitAsync to share an abstract op between them |
| 21:03 | <devsnek> | `[[Iterator]].return` certainly is not valid |
| 21:03 | <devsnek> | also since there is an explicit next function |
| 21:03 | <devsnek> | it is possible to tell whether the argument was passed |
| 21:04 | <devsnek> | although i hate that we carry that |
| 21:06 | <shu> | i ultimately didn't really like that abstract op |
| 21:06 | <shu> | too many branches |
| 21:06 | <devsnek> | i abstracted the branches out into those two macros |
| 21:06 | <devsnek> | rn i just say `If Async` |
| 21:07 | <devsnek> | i don't want to have to explicitly pass `async` and `sync` to the macros |
| 21:16 | <shu> | ultimately i wanna serve the reader |
| 21:16 | <shu> | refactorings tend to help spec maintainers, but i don't think readers read the spec like they do their own codebase |
| 21:16 | <shu> | duplication probably isn't a big deal |
| 21:17 | <shu> | it's more work for us as spec maintainers to check for copy/paste errors, but sometimes i feel like it's easier to read |
| 21:17 | <devsnek> | i just really don't want there to end up being differences and issues |
| 21:18 | <devsnek> | rn this drops 24 new methods into the spec |
| 21:20 | <ljharb> | shu: imo totally fine to split it back up if that's clearer |
