| 01:05 | <gibson042> | TabAtkins: JSON.stringify(obj, , "\t") |
| 01:17 | <TabAtkins> | Ah, instead of having to explicitly pass undefined |
| 01:17 | <TabAtkins> | I think just an empty arg is unreadable, but a shorter way to spell undefined would be nice. 😀 |
| 01:18 | <TabAtkins> | (I'm aware of `void 0`, it's still dark magic in general.) |
| 01:18 | <Bakkot> | could just make a no-operator `void` |
| 01:18 | <Bakkot> | it'd be a new and exciting ASI hazard |
| 01:19 | <rkirsling> | not like it's doin' anything with that operand anyway |
| 01:20 | <rkirsling> | I actually don't hate the idea of just an extra comma but I think the typo potential makes it a nonstarter |
| 01:20 | <rkirsling> | (or at least would be blocked at stage 2, since the problem is valid) |
| 01:53 | <devsnek> | TabAtkins: gibson042: parameters, not arguments |
| 01:54 | <devsnek> | I'm tired of doing (_, __, ... |
| 01:55 | <jridgewell> | I could see an argument for doing it in params. |
| 01:55 | <jridgewell> | We have to do `unusedX` all the time |
| 01:55 | <devsnek> | we can't have a discard identifier like rust for example |
| 01:55 | <devsnek> | so why not borrow array elisions |
| 01:57 | <devsnek> | I guess you could use void |
| 01:57 | <devsnek> | is that an asi hazard |
| 01:57 | <devsnek> | I don't think it is |
| 01:58 | <Bakkot> | it's a hazard because `let a = void\nfoo()` is already legal |
| 01:58 | <Bakkot> | actually I guess that does the right thing either way |
| 01:58 | <devsnek> | that's not legal in function parameters |
| 01:58 | <Bakkot> | `let a = void\nfunction f(){}` is probably a better example |
| 01:58 | <Bakkot> | oh, yeah, I was talking about a general way of writing undefined |
| 01:58 | <devsnek> | ah |
| 01:59 | <devsnek> | well if we stopped being COWARDS and just pretended asi didn't exist maybe we could make this language GOOD |
| 01:59 | <Bakkot> | not a problem in argument lists, but it would be kind of weird to have an expression which is only legal in argument |
| 01:59 | <Bakkot> | especially for async arrows... |
| 01:59 | <Bakkot> | I don't want to parse that |
| 02:00 | <devsnek> | it's not worse than anything we already have |
| 02:00 | <devsnek> | but yeah I prefer elisions |
| 07:49 | <annevk> | How is https://twitter.com/felixfbecker/status/1286193386685435904 true? |
| 12:46 | <devsnek> | I half wish tagged templates had a symbol protocol |
| 12:46 | <devsnek> | then you could add support for stuff like console.log |
| 12:48 | <devsnek> | I guess it could also be like `function.isTemplateCall` or smth |
| 13:16 | <bradleymeck> | annevk: not true to my knowledge unless they were in shared memory some how? |
| 13:17 | <devsnek> | bradleymeck: I think the idea is you could do a memcpy instead of a structured clone |
| 13:17 | <devsnek> | not sure how that would turn out in practice thought |
| 13:18 | <devsnek> | though* |
| 13:18 | <bradleymeck> | devsnek: but symbols? |
| 13:18 | <devsnek> | yeah |
| 13:18 | <bradleymeck> | registered, sure |
| 13:18 | <devsnek> | not sure how it would turn out in practice |
| 13:18 | <bradleymeck> | non-registered... ???? |
| 13:18 | <bradleymeck> | it would drop the identity I'd assume |
| 13:18 | <devsnek> | depends on the impl |
| 13:19 | <devsnek> | you can't ever compare them between threads so that doesn't matter |
| 13:27 | <annevk> | But we could do that for primitives already, in theory |
| 13:28 | <annevk> | Symbols throw FWIW |
| 13:28 | <annevk> | (cannot be serialized) |
| 13:40 | <devsnek> | i am *here* for `function bound get` |
| 13:40 | <devsnek> | why is my screenshot not working |
| 13:41 | <devsnek> | https://usercontent.irccloud-cdn.com/file/YUgtYQaK/63213692.png |
| 14:03 | <bradleymeck> | devsnek: you could compare them by round tripping |
| 14:04 | <devsnek> | bradleymeck: for impls that do ref equality that wouldn't work, for impls that do counting you would have to increment them i guess |
| 14:05 | <devsnek> | sucks to be the latter |
| 14:05 | <bradleymeck> | shared counters for life! (looking at you shared MS error codes) |
| 14:27 | <bradleymeck> | defaultdict in python inserts on [] but not on .get , interesting... |
| 15:28 | <shu> | annevk: i believe that can't be true without significant up-front implementation choices |
| 15:28 | <shu> | annevk: so i think i general it is not true -- it's true only in that people tend to impute a lot of performance possibility to things that are immutable |
| 15:42 | <Bakkot> | I usually have the opposite assumption |
| 15:42 | <Bakkot> | immutable = slow |
| 15:43 | <shu> | yes, i do too, but that doesn't stop the folk wisdom that immutable means things like free sharing |
| 16:56 | <devsnek> | ok so in rust there's this thing called `dbg!` and it takes its argument, prints it, and returns it |
| 16:56 | <devsnek> | i'm imagining something like |
| 16:56 | <devsnek> | `.then((r) => debug(r.json()))` |
| 16:57 | <devsnek> | maybe `.then((r) => debugger r.json())` |
| 16:57 | <devsnek> | would be nice to exist everywhere as a quick way to debug values |
| 16:58 | <bradleymeck> | bring back debugger operands? |
| 16:58 | <devsnek> | well if debugger operands are specified to return what they take sure |
| 16:58 | <bradleymeck> | special labels on debugger for now works |
| 16:58 | <devsnek> | the thing i specifically want is |
| 16:58 | <bradleymeck> | welcome to bespoke debugger tools |
| 16:58 | <devsnek> | `debug(v) -> v` |
| 16:59 | <devsnek> | so you can transparently insert it anywhere |
| 16:59 | <devsnek> | and in any js runtime |
| 16:59 | <bradleymeck> | `debugger()` isn't valid currently |
| 16:59 | <bradleymeck> | soooo |
| 16:59 | <devsnek> | yeah it could be that |
| 17:00 | <bradleymeck> | debugger`${why}` |
| 17:00 | <bradleymeck> | tagged templates would get funky |
| 17:00 | <devsnek> | i need to add all these things to my proposal idea list |
| 17:01 | <bradleymeck> | but syntax is a special form so it could just error |
| 17:02 | <devsnek> | added to list https://snek.dev/proposal-list |
| 17:03 | <bradleymeck> | function oof(, size) { return 'large'; } |
| 17:03 | <rickbutton> | snek.dev is such a great domain name |
| 17:03 | <devsnek> | ikr i love it |
| 17:03 | <devsnek> | i actually reserved it with gandi a year before .dev came out |
| 17:03 | <rickbutton> | I similarly reserved button.dev during the early bird period |
| 17:04 | <shu> | i don't know what to do with shu.dev really |
| 17:04 | <devsnek> | button is a good username |
| 17:04 | <devsnek> | put your hopes and dreams there |
| 17:04 | <rickbutton> | ^ |
| 17:04 | <shu> | i want to sell it to seton hall university for large amounts |
| 17:04 | <devsnek> | or your memes https://snek.dev/windows |
| 17:04 | <rickbutton> | invent a product called shu, sell it to company, profit |
| 17:05 | <shu> | maybe a thing to protect your feet from things on the ground |
| 17:05 | <devsnek> | genius |
| 17:05 | <rickbutton> | 🤣🤣 |
| 17:05 | <bendtherules> | Talk about impulse buy - typescript.co |
| 17:22 | <marja_> | re: outreach, pitching my blog post series "Understanding the ECMAScript spec" here: https://v8.dev/blog/understanding-ecmascript-part-4 |
| 17:22 | <rkirsling> | marja_: it's an excellent series! |
| 17:22 | <marja_> | thanks you! :) |
| 17:23 | <marja_> | *thank (argh, no edit button, what is this, twitter?) |
| 17:24 | <rkirsling> | (haha seriously) |
| 18:15 | <leobalter> | marja_: that's great indeed! The TC39 How We Work could point out to those posts. Also, I hope you can make this a recorded presentation, I'd love to share it! |
| 18:20 | <marja_> | leobalter, thanks for the idea, i'll see what i can do :) |
| 18:21 | <leobalter> | marja_: I have a recorded talk being presented this Saturday (in pt-br) that relates to these posts. I'm showing how we observe points of the specs that can be tested |
| 18:22 | <leobalter> | and it goes from a simple method to a simple syntax grammar notation |
| 18:22 | <leobalter> | (I needed to fit it in 30 minutes) |
| 18:24 | <marja_> | leobalter, oh, that sounds cool. with pt-br you mean, the talk will be in portuguese? if so, sadly i won't be able to understand it |
| 18:25 | <ystartsev> | marja_, leobalter what do you think about featuring that series on the website? |
| 18:25 | <ystartsev> | tc39.es |
| 18:26 | <leobalter> | ystartsev: that was my suggestion, so I'm totally supportive |
| 18:26 | <ystartsev> | leobalter: oh i misunderstood, i thought you meant the how we work repository |
| 18:26 | <leobalter> | ystartsev: but also, your videos are extremely helpful too |
| 18:26 | <leobalter> | ystartsev: I tend to see tc39.es and how we work as the same thing :P |
| 18:26 | <ystartsev> | yeah i think we can start collecting those resources on the website. it would make it more of a resource for peoplee |
| 18:27 | <ystartsev> | we should also publish the contents of the how we work repository _on_ the website |
| 18:27 | <marja_> | ystartsev, i support linking to the blog series from wherever people think is useful |
| 18:27 | <leobalter> | marja_: yes, in portuguese, for a Brazilian online event. I plan to later convert it to English as I'll present it internally. I believe I can then make it public |
| 18:27 | <ystartsev> | marja_: great, i will open issues |
| 18:28 | <marja_> | sounds great, thanks |
| 19:46 | <devsnek> | bradleymeck: https://docs.google.com/presentation/d/1TuLDmcjXuQmV3s6_thYCAlPaBLHO7ZM9pmCbS0oYcKw/edit#slide=id.p |
| 19:46 | <devsnek> | need to replace text with codeblocks but general idea is there |
| 19:56 | <bradleymeck> | devsnek: no share? |
| 19:56 | <devsnek> | oh sec |
| 19:58 | <devsnek> | bradleymeck: fixed |
| 20:24 | <leobalter> | I wish we could split all the ArrayBuffer/TypedArrays/DataView parts in a separate document. Not optional to ECMAScript, but easier to navigate and get references. |
| 20:24 | <devsnek> | i wish we could split the entire spec |
| 20:24 | <devsnek> | into multiple files |
| 20:24 | <devsnek> | for both authoring and viewing |
| 20:24 | <leobalter> | same |
| 20:25 | <rkirsling> | +100 |
| 20:25 | <devsnek> | people with potato devices literally can't view the spec |
| 20:26 | <leobalter> | I remember ljharb saying he doesn't want to lose the references on git history, but in my case it's not something I care that much. |
| 20:26 | <ljharb> | `git blame` is pretty important to me |
| 20:26 | <leobalter> | for Test262 the latest version is good enough and using previous edition releases are just fine |
| 20:26 | <ljharb> | splitting up the rendering is something that we should focus on first anyways, since the convenience of spec readers matters far more than that of spec authors |
| 20:27 | <Bakkot> | PRs for https://github.com/tc39/ecmarkup/issues/151 welcome |
| 20:28 | <devsnek> | wow i'm everywhere |
| 20:32 | <rkirsling> | lol |
| 20:54 | <jridgewell> | I would recommend loading the spec in Firefox |
| 20:55 | <jridgewell> | Chrome takes 1m before allowing searching |
| 20:55 | <jridgewell> | Firefox is maybe 5s |
| 20:55 | <ljharb> | works fast in safari for me |
| 20:55 | <devsnek> | jridgewell: i would recommend loading everything in firefox :P |
| 21:20 | <jmdyck> | devsnek: in dbg! slides, doSomething changes from "* 2" to "+ 1" |
| 21:20 | <devsnek> | jmdyck: business logic moves fast |
| 21:20 | <devsnek> | :^) |
| 21:20 | <devsnek> | i'll fix it some time in the next two months, thx |
| 21:20 | <jmdyck> | heh |
| 21:44 | <jmdyck> | ljharb: My review of 2065 is in progress |
| 21:44 | <ljharb> | oh great, thanks |
| 21:44 | <ljharb> | it needs another editor review before it can land anyways, but good to get yours in asap |
| 21:45 | <Bakkot> | jmdyck btw we talked about the infinity thing and are probably going to try to add extended mathematical values which include infinity |
| 21:45 | <Bakkot> | I am going to make a PR against 2007 as soon as I get a chance |
| 21:46 | <Bakkot> | so much to do, so much to do |
| 21:46 | <michaelficarra> | can we just call them reals and extended reals? |
| 21:47 | <michaelficarra> | the MV term is so long |
| 21:47 | <devsnek> | we could call them real mathematical values and extended real mathematical values |
| 21:47 | <jmdyck> | I stopped work on 2007 when my static analyzer broke and I wasn't sure how to fix it. |
| 21:47 | <rkirsling> | proposal for ω please |
| 21:48 | <Bakkot> | jmdyck hopefully I will get it into a state where your analyzer works again! |
| 21:48 | <jmdyck> | are you doing anything with the time stuff? |
| 21:49 | <Bakkot> | let me check |
| 21:49 | <Bakkot> | I see that I noted that all the date math operates on numbers as if they were mathematical values |
| 21:49 | <Bakkot> | so, yes, probably I will try to fix that |
| 21:51 | <Bakkot> | also, if you are inclined to, if you push up your ecmaspeak branch with whatever work you've done on it I will run it as I work on this and see where it chokes, which will probably suggest a place I need to fix anyway |
| 21:51 | <jmdyck> | yeah, all the emu-eqns look like mathematical, but the builtins are dealing with numbers, and it's not clear where the conversions should occur. |
| 21:53 | <Bakkot> | all the emu-eqns in the Date section, specifically? |
| 21:54 | <jmdyck> | that's what I meant, yeah. |
| 21:54 | <Bakkot> | got it |
| 21:54 | <Bakkot> | will note to self to fix |
| 22:00 | <bradleymeck> | emplace/upsert/newname is looking at splitting the proposal for whoever remains interested : https://github.com/tc39/proposal-upsert/issues/31 |
| 22:10 | <jmdyck> | ljharb: I've submitted my review of 2065. There's more analysis I want to do, but it probably wouldn't end up touching 2065 particularly. |
