| 06:23 | <jschoi> | ljharb: With regard to https://github.com/tc39/proposal-pipeline-operator/issues/310#issuecomment-2696324408, is there an actual “Tennent’s correspondence principle” of PL design that we’re trying not to break? The best answer I can find defining that phrase is https://softwareengineering.stackexchange.com/questions/116395/what-is-the-good-explanation-of-tennents-correspondence-principle, which seems to be some descriptive advice regarding correspondence between variable definitions and producer parameters. (I do still agree that we should do our best to avoid any variables, for what it’s worth. Right now, under https://github.com/tc39/proposal-pipeline-operator/wiki/Bikeshedding-the-Hack-topic-token#disqualified-tokens, variable identifiers are disqualified because variable tokens “may unexpectedly shadow outer variables”. Which is true.) |
| 06:31 | <rkirsling> | it's a TODO item in the terminology doc https://github.com/tc39/how-we-work/blob/main/terminology.md#todo-considerations |
| 06:33 | <jschoi> | rkirsling: Nice, thanks for pointing me there. It's been a while. |
| 06:34 | <rkirsling> | but yeah it's a deep cut that seems to lack a primary source(??) yet https://fanf.livejournal.com/118421.html gives a clear sentence of "the meaning of an expression or statement should not change when an extra level of block structure is added around it" |
| 06:36 | <jschoi> | It's a pretty good goal. Even if it doesn't seem to actually have been named by Tennent—at least according to Crockford. We might want to give it a better name… |
| 06:36 | <jschoi> | It's a manifestation of the general goal to reduce modality and contextuality of code as much as possible, to reduce cognitive burden. |
| 06:36 | <rkirsling> | honestly agree |
| 06:37 | <rkirsling> | just give it our own name and relay credit for the idea where it's due |
| 06:39 | <rkirsling> | ('cause hell, even the acronym is terrible -- who wants to overload TCP 😂) |
| 07:29 | <ljharb> | definitely - https://yehudakatz.com/2012/01/10/javascript-needs-blocks/ https://www.tomshouseofdollars.com/Tennent/ |
| 07:30 | <ljharb> | it’s been on tc39 bingo for a long time :-p |
| 07:30 | <rkirsling> | yeah but not like, in a continuous way |
| 07:31 | <rkirsling> | it's one of those "you had to be there, otherwise for years you're just like what's the deal with that anytime it comes up" phrases |
| 07:32 | <rkirsling> | like it always looks like a misspelling of David Tennant's name and I'm like, what's Dr. Who got to do with it |
| 08:03 | <jschoi> | It really does need a better name than a false eponym. Like “block-wrapped equivalence” or “in-block identity”. |
| 08:19 | <rkirsling> | or something like "invariance under rescoping" or "scope context (in)sensitivity" |
| 08:27 | <Ashley Claymore> | Single Semantic Scope |
| 08:31 | <jschoi> | “Stable Under Scope”: “That variable is SUS.” 🔪 “Stable Between Scopes”: “That variable is SBS.” |
| 08:33 | <jschoi> | (I kind of suspect that that new #310 issue was LLM generated; it has that feeling…) |
| 17:10 | <TabAtkins> | Hm, yeah, a better name is indeed needed. We have a similar policy in CSS that adding an unstyled inline between some text and an ancestor should not cause observable behavior changes in any inherited properties specified on the ancestor; we refer to it informally as "inline transparency" |
| 17:12 | <TabAtkins> | Additional Scope Transparency, I don't think there's any other PL-related AST acronym ^_^ |