| 00:01 | <devsnek> | Bakkot: https://github.com/bmeck/proposal-arbitrary-module-namespace-identifiers |
| 00:01 | <bradleymeck> | it never made it to stage 1, but https://github.com/bmeck/proposal-arbitrary-module-namespace-identifiers has it and spec text |
| 00:01 | <bradleymeck> | it gets merged on stage 1 from my previous exp |
| 00:02 | <devsnek> | oh i thought it had stage 1 |
| 00:02 | <bradleymeck> | missed deadline last time |
| 00:02 | <devsnek> | ah |
| 00:02 | <bradleymeck> | really the only confusing bit is the utf8 verification |
| 00:03 | <devsnek> | that's like a stage 3 concern though |
| 00:03 | <devsnek> | can wait until 2025 to figure that out |
| 00:03 | <bradleymeck> | rest is kind of odd syntax but seems fine |
| 00:03 | <bradleymeck> | devsnek: it was already checked by mathiasbynens and it looks like we only need to be sure it doesn't have unpaired surrogates |
| 00:04 | <devsnek> | makes sense |
| 00:04 | <devsnek> | in entirely unrelated news, i added numeric separators to engine262 |
| 00:08 | <bradleymeck> | fun fun! |
| 00:08 | <devsnek> | i'm just putting off the stuff i actually need to fix like assignment patterns |
| 00:17 | <bradleymeck> | i can feel ya, i was using an AST and noticed I couldn't differentiate MemberExpression as Reference vs Value in it and just took a break from porting some stuff |
| 00:23 | <Bakkot> | that is a distinction Shift makes! |
| 00:23 | <Bakkot> | and yeah, forbidding unpaired surrogates is the only necessary thing there |
| 00:24 | <Bakkot> | which we should do, I feel strongly |
| 00:26 | <Bakkot> | bradleymeck actually, on that note, do we maybe want to constrain Abstract Module Record to require valid unicode for specifier names? |
| 00:26 | <Bakkot> | doesn't affect ES currently, afaict |
| 00:26 | <bradleymeck> | Bakkot: shift does not differentiate that to my knowledge? cause that is what i was dealing with |
| 00:27 | <Bakkot> | and I doubt anyone is using wasm modules with unpaired surrogates in their specifier names |
| 00:27 | <bradleymeck> | Bakkot: I think it would be fine to limit those names |
| 00:27 | <bradleymeck> | Bakkot: unpaired are invalid in wasm |
| 00:27 | <bradleymeck> | thats the only real reason i care |
| 00:27 | <bradleymeck> | but non-characters are supported so 🤷 |
| 00:27 | <Bakkot> | bradleymeck: shift distinguishes MemberAssignmentTarget and MemberExpression |
| 00:28 | <Bakkot> | is that not what you are looking for? |
| 00:28 | <bradleymeck> | `delete THIS.SHOULD.BE.A.REF` |
| 00:28 | <Bakkot> | re: wasm, sweet |
| 00:28 | <Bakkot> | ahhh |
| 00:28 | <Bakkot> | delete is weird, yes. I could see an argument for changing that, actually |
| 00:28 | <bradleymeck> | also for calls |
| 00:28 | <Bakkot> | not so much for calls though |
| 00:28 | <bradleymeck> | since you want to know which base gets the `this` |
| 00:29 | <Bakkot> | hm, hm |
| 00:29 | <bradleymeck> | x.y() => call { callee : member expression : {x, y} } |
| 00:29 | <Bakkot> | I guess I would prefer to fix that via an explicit membercall node type, if we wanted that |
| 00:29 | <bradleymeck> | so you have to convert member expressions to always be refs and then unwind it depending on exterior position |
| 00:29 | <bradleymeck> | 🤷 every AST has its compromises |
| 00:30 | <bradleymeck> | not like there is a univerally perfect solution |
| 00:30 | <bradleymeck> | Bakkot: re: banning non-UTF names, probably just a normative PR? |
| 00:30 | <Bakkot> | yup |
| 00:31 | <Bakkot> | in advance of the proposal, probably |
| 00:31 | <bradleymeck> | some of the syntax productions used in these areas are a big questionable too but i'm in no rush to fix that |
| 00:31 | <bradleymeck> | Bakkot: I'd welcome an abstract op |
| 00:31 | <bradleymeck> | honestly just a fn that complains about if a string is not fully unicode would be great |
| 00:32 | <Bakkot> | if you open a normative PR using such an AO and leave its definition as a TODO I or someone else will fill it out if it gets consensus |
| 00:40 | <Bakkot> | also would back a `String.prototype.isValidUnicode` proposal, which I seem to recall discussing at some point |
| 00:40 | <Bakkot> | maybe with mathiasbynens |
| 00:40 | <devsnek> | maybe we just need a new string type |
| 00:40 | <Bakkot> | (would also accept `String.isValidUnicode(foo)`) |
| 00:40 | <devsnek> | we're adding new numbers, new time stuff, etc |
| 00:40 | <devsnek> | time for new strings |
| 00:42 | <bradleymeck> | Bakkot: i vaguely prefer string.isValidUnicode since it coercing seems fine |
| 00:42 | bradleymeck | stares angrily at Buffer in node |
| 00:43 | <Bakkot> | wfm I guess |
| 00:44 | <devsnek> | we should put the text encoding api in ecma262 |
| 00:45 | <bradleymeck> | weren't people objecting to that |
| 00:45 | <devsnek> | i'm sure someone somewhere would object to that |
| 00:56 | <Bakkot> | I think people objected to that yes |
| 00:56 | <Bakkot> | it has been raised |
| 05:34 | <mathiasbynens> | Bakkot: re: `String.prototype.isValidUnicode`, I remember that! annevk was involved too. I think the name we had in mind back then was `.isWellFormed` or some such |
| 06:50 | <annevk> | Thanks for the ping, yeah, that's something I'm interested in |
| 06:51 | <annevk> | It would let me close https://github.com/whatwg/encoding/issues/174 |
| 12:51 | <bradleymeck> | mathiasbynens: i can make a proposal if none exits? |
| 12:51 | <bradleymeck> | its a tiny op |
| 12:54 | <mathiasbynens> | bradleymeck: i can't find the relevant github thread anymore (not sure which repo it was on), but iirc the general sentiment was that this is easy enough to polyfill |
| 12:55 | <bradleymeck> | mathiasbynens: with arbitrary module namespace names the op would be in the spec anyway |
| 12:55 | <bradleymeck> | and the polyfill is a pain to explain |
| 12:57 | <mathiasbynens> | bradleymeck: https://github.com/whatwg/encoding/issues/174#issuecomment-480735701 |
| 12:58 | <mathiasbynens> | bradleymeck: to be clear, I'm not opposed! this was just the pushback I anticipated. it certainly keeps coming up regularly, so maybe we should just do it now |
| 12:59 | <bradleymeck> | mathiasbynens: if we are limiting names and we have the op, I want it just because I can point to tests in node that do fail to actually test this |
| 12:59 | <bradleymeck> | streams of various kinds often just do body = ""; on('data', _ => body += _) |
| 13:00 | <bradleymeck> | and that is... not bueno |
| 14:14 | <bradleymeck> | Bakkot: i'm leaving it at https://bmeck.github.io/proposal-arbitrary-module-namespace-identifiers/#sec-isvalidunicode but it is extracted |
| 14:14 | <bradleymeck> | we just don't use it anywhere right now so no ECMA262 PR |
| 14:15 | <bradleymeck> | feel free to steal and make a PR about abstract module namespace names |
| 14:50 | <devsnek> | Bakkot: so basically the async generator behaves the same way *except* you have to explicitly `await` yields and returns to catch the exceptions |
| 14:50 | <devsnek> | so probably not web compatible |
| 16:41 | <leobalter> | Bakkot you're one of my best references for syntax grammar, can you help me and caiolima on this one, please? https://github.com/tc39/proposal-class-fields/pull/313#issuecomment-660078419 |
| 16:50 | <Bakkot> | leobalter I agree with your interpretation, though not your proposed fix |
| 16:50 | <Bakkot> | will comment |
| 16:51 | <leobalter> | I don't like how long my proposed fix is, and I'd love to make it _smarter_ |
| 16:54 | <devsnek> | "It is an early error if you try to delete a private field" ez |
| 16:59 | <Bakkot> | leobalter commented |
| 17:30 | <Bakkot> | bradleymeck mathiasbynens: fwiw, while I think "is easy to polyfill" can be a reasonable argument against a proposal, my position is that it's usually not a good argument when the thing being proposed is a single primitive operation |
| 17:31 | <Bakkot> | and I think "is this string valid unicode" is a single primitive operation |
| 17:31 | <Bakkot> | I think it's worth bringing to committee on that basis |
| 17:35 | <ljharb> | also i think "easy" needs to not just mean "easy for an expert"; i'd bet most people can't easily polyfill "is this valid unicode" |
| 17:44 | <Bakkot> | yeah that's also a fair point |
| 17:44 | <michaelficarra> | ljharb: that's actually pretty easy to do |
| 17:45 | <Bakkot> | michaelficarra it's easy if you know what surrogate pairs are |
| 17:45 | <ljharb> | which most don't |
| 17:45 | <Bakkot> | how many JS programmers know what surrogate pairs are? |
| 17:45 | <michaelficarra> | he didn't say UTF-16, he said Unicode |
| 17:45 | <Bakkot> | the way that JS strings fail to be valid unicode is by having unpaired surrogates |
| 17:45 | <devsnek> | don't roll your own unicode |
| 17:46 | <ljharb> | i've also bet most users don't have any idea that the length of 💩 is 2 |
| 17:46 | <ljharb> | *i'd |
| 17:46 | <devsnek> | no one ever takes the length of a poop emoji |
| 17:46 | <devsnek> | so it doesn't matter |
| 17:46 | <michaelficarra> | devsnek: you can't be serious |
| 17:47 | <ljharb> | emoji usage is very high, and code that splits strings might end up with half poos |
| 17:47 | <devsnek> | ok unless you're twitter |
| 17:47 | <ljharb> | or 3/4ths of a flag |
| 17:47 | <Bakkot> | twitter's definition of 'the length of string' is pretty interesting |
| 17:47 | <Bakkot> | "Later in 2017, Twitter increased the maximum Tweet length from 140 to 280 Unicode code points... except that code points U+1100 HANGUL CHOSEONG KIYEOK upwards now counted double. This effectively divided Unicode into "light" code points and "heavy" code points." |
| 17:48 | <Bakkot> | though I vaguely recall for a while they were only making that distinction client-side, and server-side they were using the "number of unicode code points" definition |
| 17:48 | <devsnek> | is that the point at which you flip between letters and glyphs |
| 17:48 | <ljharb> | i mean, there's definitely some tweets that are heavy and some that are light |
| 17:48 | <Bakkot> | what is this "letter" vs "glyph" distinction you allude to |
| 17:48 | <devsnek> | probably the wrong words but like |
| 17:49 | <michaelficarra> | lol devsnek you are like little baby |
| 17:49 | <devsnek> | you need more letters in english to make a word than you do in japanese |
| 17:49 | <michaelficarra> | ideographs is the word you're looking for |
| 17:50 | <devsnek> | aha |
| 17:50 | <ljharb> | i remember (before the 280 char bump, at least), you could tweet a lot more words in chinese/japanese than you could in english for that reason |
| 17:50 | <Bakkot> | there is not a point where unicode switches from being phonetic letters to being ideographs |
| 17:50 | <Bakkot> | they are mixed, alongside other symbols |
| 17:50 | <michaelficarra> | ^ |
| 17:50 | <devsnek> | well there goes my theory |
| 17:51 | <shu> | i mean ideographs are also kinda phonetic |
| 17:52 | <Bakkot> | yeah also there is not a clean distinction between "ideographs" and "phonetic letters" |
| 17:52 | <shu> | japanese is straight up mixed with syllabaries |
| 17:52 | <shu> | but even in chinese, we use some radicals only for their sound |
| 17:52 | <michaelficarra> | devsnek: here's a good reference: https://en.wikipedia.org/wiki/Plane_(Unicode)#/media/File:Roadmap_to_Unicode_BMP.svg |
| 17:53 | <michaelficarra> | that's just the BMP |
| 17:55 | <devsnek> | i think its time we assign each english letter its own meaning |
| 17:55 | <devsnek> | F and I are already done |
| 17:55 | <michaelficarra> | "English" letter...? |
| 17:55 | <devsnek> | letter used in english |
| 17:55 | <devsnek> | wherever they came from |
| 17:56 | <Bakkot> | is ö an english letter? |
| 17:56 | <Bakkot> | I guess that depends on whether you work for the New Yorker |
| 17:56 | <devsnek> | lol |
| 17:57 | <Bakkot> | if `&` is a letter it has a meaning |
| 17:57 | <michaelficarra> | oh you mean like þ |
| 17:58 | <Bakkot> | (well, "&" has meaning either way I guess, just it only counts towards this project if it is a letter) |
| 17:58 | <michaelficarra> | Bakkot: unfortunately, Unicode doesn't consider & a letter |
| 17:58 | <Bakkot> | unfortunate |
| 17:59 | <michaelficarra> | yeah that one's really questionable |
| 17:59 | <michaelficarra> | if æ is a letter, & should be, too |
| 18:00 | <Bakkot> | "&" is funny because sometimes it is its own word and sometimes it is part of one, like "&c" |
| 18:00 | <Bakkot> | though I guess that is a lot of letters work... |
| 18:01 | <devsnek> | what is &c |
| 18:01 | <devsnek> | oh an abbreviation of et cetera |
| 18:01 | <devsnek> | never seen that before |
| 18:02 | <ljharb> | iirc that's the origin of "et cetera" |
| 18:03 | <ljharb> | or maybe it's the other way around, i dunno |
| 18:04 | <michaelficarra> | et was "merged" to & over time, you can see a lot of cool examples of the progression |
| 18:04 | <Bakkot> | "et" is the origin of "&" |
| 18:04 | <ljharb> | ahhh k |
| 18:05 | <michaelficarra> | which is why I say that æ being a letter implies & should be too |
| 18:05 | <devsnek> | its a codepoint |
| 18:05 | <devsnek> | good enough right |
| 18:06 | <michaelficarra> | devsnek: you make me sad |
| 18:07 | <devsnek> | :( |
| 18:07 | <devsnek> | what is a letter but a miserable pile of secrets |
| 18:09 | <michaelficarra> | I don't think I understand the question |
| 18:10 | <Bakkot> | is "墸" an ideogram |
| 18:10 | <devsnek> | what a deep and philosophical question |
| 18:11 | <michaelficarra> | Bakkot: yes |
| 18:11 | <Bakkot> | michaelficarra what idea or concept does it represent |
| 18:11 | <michaelficarra> | Bakkot: that's not up to Unicode to determine |
| 18:12 | <michaelficarra> | except for emojis, in which case that's the whole point |
| 18:12 | <Bakkot> | let me put it another way: when they put it in, no human associated an idea or concept with that specific symbol |
| 18:12 | <michaelficarra> | true, but it was explicitly declared to be an ideograph, so it is |
| 18:13 | <Bakkot> | is that how that works? |
| 18:14 | <Bakkot> | "an ideograph is that which the unicode consortium calls an ideograph" is not a very satisfying definition |
| 18:14 | <michaelficarra> | let's say Unicode encoded ☢ 100 years ago |
| 18:15 | <devsnek> | satisfyingly simple |
| 18:15 | <michaelficarra> | it is an ideograph, but nobody would have any idea what it meant |
| 18:15 | <michaelficarra> | later, we would assign meaning to it |
| 18:15 | <michaelficarra> | possibly, many years from now, it may come to mean something else to the majority of us |
| 18:16 | <devsnek> | in a sense they're all ideographs |
| 18:16 | <michaelficarra> | similar to 🍆 |
| 18:16 | <Bakkot> | I don't think that whether or not a particular symbol is an ideograph must necessarily be time-invariant |
| 18:16 | <michaelficarra> | devnsek: that's not correct, letters just aren't ideographs because they have to be composed into a word |
| 18:16 | <devsnek> | if i send a single F |
| 18:17 | <Bakkot> | f |
| 18:17 | <devsnek> | i think most people understand that to have a meaning |
| 18:17 | <michaelficarra> | there are words composed of single letters, but those are different things |
| 18:17 | <devsnek> | well most people who speak english at least |
| 18:17 | <devsnek> | it's different from "I" |
| 18:17 | <michaelficarra> | how? |
| 18:17 | <devsnek> | it's not a word |
| 18:18 | <Bakkot> | I guarantee "most" english speakers would not understand what you meant by the single letter "f" |
| 18:18 | <devsnek> | well, a good amount, probably not more than half |
| 18:18 | <michaelficarra> | devsnek: why is it not a word? |
| 18:18 | <michaelficarra> | because it's not in the dictionary? |
| 18:19 | <ljharb> | lol let's not get into prescriptivism vs descriptivism |
| 18:19 | <michaelficarra> | language is ever-changing, words come and go and change meaning all the time |
| 18:19 | <devsnek> | the same way ☢ isn't a word |
| 18:19 | <devsnek> | even though it has a meaning |
| 18:19 | <michaelficarra> | it's not a word because it's not composed of letters lol |
| 18:19 | <shu> | this discussion pains me |
| 18:19 | <devsnek> | lmao |
| 18:20 | <shu> | we can all attend some intro to linguistics and philosophy of language courses then come back and debate this |
| 18:20 | <ljharb> | aren't words in ideographical languages not composed of letters |
| 18:20 | <devsnek> | i actually took intro to linguistics |
| 18:20 | <devsnek> | i don't remember most of it |
| 18:22 | <Bakkot> | shu I am basically shitposting my way through this conversation on the assumption that everyone here is aware that these questions do not and cannot have objectively correct answers |
| 18:22 | <devsnek> | ^ |
| 18:22 | <michaelficarra> | Bakkot: they have prescribed answers from Unicode |
| 18:22 | <michaelficarra> | well, a lot of them do |
| 18:23 | <Bakkot> | michaelficarra yeah but we do not have agreement that Unicode is the single source of truth |
| 18:23 | <michaelficarra> | ahem, <points at UNI> |
| 18:23 | <Bakkot> | otherwise "was the consortium correct to say & is not a letter" would not be a meaningful question |
| 18:23 | <devsnek> | looking forward to SARCASTIC_RESPECTFUL_F |
| 18:25 | <Bakkot> | 𝔉 |
| 18:25 | <ljharb> | ⸮ |
| 18:26 | <michaelficarra> | 🪦 |
| 18:26 | <devsnek> | TIL there's a headstone emoji |
| 18:26 | <ljharb> | michaelficarra: that's a box for me |
| 18:27 | <michaelficarra> | ljharb: Apple's emoji support is terrible |
| 18:28 | <michaelficarra> | ljharb: can you see ㋿? |
| 18:29 | <bradleymeck> | michaelficarra: i see box then a character |
| 18:30 | <bradleymeck> | "SQUARE ERA NAME REIWA" |
| 18:30 | <michaelficarra> | wow weird |
| 18:30 | <ljharb> | michaelficarra: yep, i see ㋿ |
| 18:30 | <Bakkot> | 12.1 is less than 13 |
| 18:31 | <devsnek> | by 0.9 |
| 18:31 | <michaelficarra> | Bakkot: I'm trying to see how out of date his support is |
| 18:31 | <devsnek> | make a website with a character from each version |
| 18:31 | <michaelficarra> | ljharb: by "see" do you mean it's rendered correctly? |
| 18:31 | <Bakkot> | devsnek by about 300 days |
| 18:32 | <michaelficarra> | devsnek: I already have lol |
| 18:32 | <devsnek> | wow not even a year |
| 18:32 | <ljharb> | michaelficarra: i mean, i could share a screenshot, but i see a character and not a box |
| 18:32 | <michaelficarra> | devsnek: yeah there's a pretty funny story behind the Unicode 12.1 release |
| 18:32 | <devsnek> | sounds like es4 |
| 18:33 | <devsnek> | > Unicode 12.1 adds exactly one character |
| 18:33 | <ljharb> | michaelficarra: https://emojipedia.org/headstone/ says "second half of 2020", so it doesn't seem that out of date |
| 18:33 | <devsnek> | oh i'm caught up now |
| 18:33 | <devsnek> | cuz of the new japanese era announcement |
| 18:33 | <ljharb> | reiwa was over a year ago |
| 18:35 | <ljharb> | not sure i'd classify "this year's new emoji" not being supported as "terrible" ¯\_(ツ)_/¯ |
| 18:35 | <shu> | i see ㋿ as rei then wa real squished? |
| 18:35 | <devsnek> | ya same |
| 18:35 | <Bakkot> | I wonder if the Japanese emperor is the sole person who has unilateral authority to cause a character to be added to unicode |
| 18:36 | <ljharb> | visually i see three vertical pieces squished into one, the first is a trianglish one on top of a P-ish one; the second looks like a tree, and the third looks like one of those medieval hanging flags with a forked bottom |
| 18:36 | <Bakkot> | (but just one character) |
| 18:36 | <devsnek> | just need to get the president to add a new letter to english |
| 18:36 | <devsnek> | that's how that works right |
| 18:37 | <Bakkot> | I prefer not to think about that question |
| 18:37 | <michaelficarra> | devnsek: languages and scripts are different things |
| 18:39 | <michaelficarra> | ljharb: hasn't been updated for 14 months, in the world of software, is pretty bad |
| 18:39 | <Bakkot> | michaelficarra it's still 2020 |
| 18:39 | <Bakkot> | believe it or not |
| 18:40 | <ljharb> | it's not that it hasn't been updated in 14 months, it's that it hasn't been updated since march 10th when unicode 13 came out |
| 18:40 | <ljharb> | michaelficarra: so, 4 months |
| 18:40 | <ljharb> | which is not bad |
| 18:46 | <michaelficarra> | fair, let's see when they get Unicode 13 support |
| 18:47 | <ljharb> | i'm assuming it'll be by september, since that's when new MacOS's and safari's tend to come out |
| 18:49 | <michaelficarra> | hopefully it coincides with an important security update since that's apparently the only thing that causes people to update |
| 18:51 | <ljharb> | imo people update for shiny features far more often than for any security updates |
| 18:56 | <rkirsling> | holy shit how did I miss this whole conversation |
| 18:56 | <rkirsling> | it's so long to catch up on too |
| 18:56 | <devsnek> | don't feel pressured to catch up |
| 18:57 | <Bakkot> | the sole actual content is 'yeah, String.isValidUnicode (or whatever name) is probably a good idea' |
| 18:58 | <rkirsling> | devsnek: oh no I wouldn't be whining if it weren't relevant to my interests lol |
| 19:02 | <rkirsling> | Bakkot: fair enough lol |
| 19:03 | <rkirsling> | I liked that 墸 came up |
| 19:03 | <rkirsling> | and ljharb's visual description of ㋿ 😂 |
| 19:07 | <ljharb> | :-p |
| 19:53 | <bendtherules> | Since people are in shitposting mood, let me ask something I have wondered about for some time - |
| 19:53 | <bendtherules> | How does the spec explain closure thingy? |
| 19:53 | <bendtherules> | Is it more of a yeah, any function can access outer variables (with no Implementation details) or something more specific (tells which variables to capture) ? |
| 19:55 | <Bakkot> | every function has an environment, variables are stored in environments and looked up by name when used |
| 19:55 | <Bakkot> | the whole "which variables to capture" thing isn't decidable in general because of `with` and direct `eval` |
| 19:55 | <devsnek> | blocks have environments too |
| 19:55 | <Bakkot> | I guess I should rather say that every function has an environment _chain_ |
| 19:55 | <devsnek> | and switches |
| 19:56 | <devsnek> | and functions store which environment they are in |
| 19:56 | <devsnek> | in a manner of speaking |
| 19:56 | <devsnek> | https://tc39.es/ecma262/#sec-newfunctionenvironment |
| 19:57 | <bendtherules> | So, inner function looks up own env, then outer env - but it doesn't say how long a env should exist if the function execution is completed? |
| 19:57 | <devsnek> | the spec doesn't say how long anything should exist |
| 19:58 | <devsnek> | well i guess it gives minimums |
| 20:02 | <bendtherules> | devsnek: hmm. |
| 20:02 | <bendtherules> | Related question - environment seems to contain env record. Is there any operation where this env record is removed from from one env and moved to another? Or is Environment to Env record practically a 1:1 mapping? |
| 20:03 | <devsnek> | which spec are you reading |
| 20:03 | <devsnek> | we got rid of the "environment" vs "environment record" thing |
| 20:04 | <jmdyck> | Well, we got rid of LexicalEnvironment as a thing |
| 20:05 | <jmdyck> | sorry, "Lexical Environment". |
| 20:05 | <devsnek> | bendtherules: if you aren't already, you should reference tc39.es/ecma262 |
| 20:05 | <jmdyck> | ("LexicalEnvironment" is still the name of a component of execution context) |
| 20:06 | <devsnek> | that refactoring is the one time i have wanted to use typescript |
| 20:07 | <jmdyck> | I think the spec still uses "environment" somewhat casually to mean the same thing a Environment Record. |
| 20:08 | <jmdyck> | (and also in other phrases, e.g. "the host environment") |
| 20:09 | <Bakkot> | there its use is not the same as environment record |
| 20:09 | <Bakkot> | "host environment" will have a formal definition as of https://github.com/tc39/ecma262/pull/1951 |
| 20:10 | <jmdyck> | yeah, that's what i meant. |
| 20:10 | <jmdyck> | "also" as in "also, with another meaning" |
| 20:11 | <jmdyck> | so bendtherules, I don't think it's ever been true that "an environment contains an environment record" |
| 20:11 | <devsnek> | it contains an outer environment |
| 20:12 | <jmdyck> | that's not a containment relaionship. |
| 20:12 | <bendtherules> | Right. I read once more and only found env records. |
| 20:12 | <jmdyck> | or, you could say it contains a reference to an outer env. |
| 20:12 | <bendtherules> | Maybe that's the mental mapping i had for some reason |
| 20:13 | <devsnek> | jmdyck: well that argument starts to get into the memory layout of records |
| 20:13 | <jmdyck> | which is why i wouldn't make that argument |
| 20:15 | <devsnek> | my point was just that saying "contains" is a bit silly since it's the same relationship either way |
| 20:20 | <bendtherules> | So, LexicalEnvironment and VariableEnvironment (parts of the execution context) - are they used to "skip" a lookup when you want to declare a var? |
| 20:20 | <bendtherules> | Mental model for me is var looks up the closest function, but spec just uses current VariableEnvironment |
| 20:21 | <devsnek> | there's basically two lists of environments |
| 20:21 | <devsnek> | one for lexical declarations and one for variable declarations |
| 20:21 | <bendtherules> | And also, is VariableEnvironment always a parent or same as LexicalEnvironment? |
| 20:22 | <devsnek> | its less about "skipping" and more about them not lining up |
| 20:22 | <bendtherules> | Devsnek - but sometimes they do refer to the same thing, no? |
| 20:22 | <devsnek> | yes |
| 20:23 | <bendtherules> | So, function always adds a entry for both. |
| 20:23 | <bendtherules> | But i would have thought that functions without a block statement doesn't need a LexicalEnvironment? |
| 20:24 | <bendtherules> | Like `() => 123` |
| 20:25 | <bendtherules> | Although this doesn't have a visible impact anyway |
| 20:25 | <devsnek> | generally a new lexical environment isn't added |
| 20:26 | <Bakkot> | the spec doesn't really go out of its way to avoid creating spec objects |
| 20:26 | <devsnek> | that too |
| 20:26 | <bradleymeck> | it doesn't at all |
| 20:26 | <devsnek> | well sometimes it does |
| 20:27 | <bradleymeck> | i think the only time it does is to make sure references are the same? do we do it elsewhere? |
| 20:28 | <devsnek> | hm i guess for "out of its way" yeah it doesn't |
| 20:28 | <Bakkot> | FunctionDeclarationInstantiation does this, but it shouldn't |
| 20:28 | <devsnek> | wasn't there a bunch of discussion about that |
| 20:29 | <Bakkot> | yup |
| 20:40 | <bendtherules> | Different question - Why do some statements return NormalCompletion with a explicit value? Where is this used? I understand the need in expressions |
| 20:41 | <Bakkot> | eval |
| 20:41 | <Bakkot> | let x = eval('if(Math.random()<.5)0; else 1;'); console.log(x) |
| 20:41 | <bendtherules> | oh, never thought of that |
| 20:42 | <bendtherules> | And these values have legit usage? |
| 20:44 | <Bakkot> | I don't know what "legit" means here |
| 20:44 | <Bakkot> | certainly making that line of code not work would break a bunch of websites, yes |
| 20:45 | <bendtherules> | I meant like people actually use this? Not suggesting that it should be modified or anything. |
| 20:45 | <bendtherules> | I understand, so more of a compatibility thing |
| 20:48 | <Bakkot> | I would not recommend using this, to be clear |
| 20:49 | <Bakkot> | but there is a lot of JS in the world, and a lot of people writing more of it all the time |
| 20:50 | <Bakkot> | also I should mention that these will maybe start getting use if do expressions go forward: https://github.com/tc39/proposal-do-expressions/ |
| 20:50 | <Bakkot> | I hoped to work on that in time for this meeting, but have had too much other stuff |
| 20:50 | <bendtherules> | Ahh, I was just looking at that 😀 |
| 23:01 | <shu> | devsnek: i'm out of time today to re-review your CL, and with TC39 i might not get to it again until next next week, is that okay? |
| 23:01 | <devsnek> | np |
| 23:01 | <shu> | thanks |
#/media/File:Roadmap_to_Unicode_BMP.svg){kind=link}