| 17:10 | <ptomato> | is the notation record.[[<nameOfField>]] OK to use in ECMA-262? it's used plenty in ECMA-402, but there are no examples of it in 262 as far as I can see |
| 17:12 | <ryzokuken> | "the field name of record" was suggested |
| 17:21 | <ptomato> | with angle brackets? |
| 17:23 | <ryzokuken> | no, I just realized you meant it with the brackets |
| 17:23 | <nicolo-ribaudo> | Is name a variable? |
| 17:24 | <ryzokuken> | yeah |
| 17:24 | <ryzokuken> | same as nameOfField |
| 17:27 | <bakkot> | ecma262 does not use that notation currently, and we as editors would generally prefer to avoid it if at all possible |
| 17:27 | <bakkot> | what's the context in which you need that? |
| 17:32 | <ptomato> | just wondering about phrasing like https://github.com/tc39/proposal-temporal/pull/2429/files#diff-ceec2609082b71fe76df3f43d148b97d667dde310f51a514141886246bf3fc74R1058 |
| 17:34 | <ptomato> | "Set the field of record whose name is fieldName to value" seems like it could be better expressed, and indeed ECMA-402 consistently does "Set record.[[<fieldName>]] to value" |
| 17:45 | <bakkot> | Personally I would just write out the fields, instead of trying to use a loop |
| 17:45 | <bakkot> | cc shu ^ |
| 17:50 | <ptomato> | fair enough. perhaps this is a good reason to move https://github.com/tc39/how-we-work/pull/119 forward so we could stick that in there? 😇 |
| 17:55 | <shu> | i would strongly prefer to write out the fields instead of using a loop |
| 17:56 | <shu> | using a loop over table has at least two major downsides for the reader. 1) the table is non-local, so i have to open another window or something to match up 2) it results in hard to understand state-keeping between iterations that are really just mystified ways to apply some logic to a particular field |
| 17:56 | <shu> | both of which are directly avoided by just writing the fields out inline |
| 19:15 | <ptomato> | shu: bakkot: so, this? |
| 19:18 | <ptomato> | that doesn't seem to me like an improvement for the reader, but that opinion is based on a survey of exactly one reader (me) 😄 |
| 19:59 | <shu> | yes |
| 20:00 | <shu> | i consider that an improvement as a reviewer of temporal patches |
| 20:43 | <nicolo-ribaudo> | As a first-time reader of the temporal spec, the new version looks more readable to me |
| 20:47 | <nicolo-ribaudo> | There are more things to read, but they require less effort |
| 20:52 | <snek> | wasm people say our spec is pretty good for automated mechanization (in comparison to the c++ one 😄) |
| 20:53 | <shu> | lol suck it formalisms |
| 20:54 | <snek> | webassembly is the easiest though because they have formal semantics in the spec for every operation :) |
| 21:02 | <bakkot> | lol that screenshot is old |
| 21:03 | <bakkot> | you can tell because we actually replaced the "result of evaluating |x|" thing with "Evaluation of |x|" so that it would be more consistent |
| 21:03 | <snek> | can't win them all |
| 21:03 | <snek> | but its still a lot better than c++ which is just a paragraph of vague requirements |
| 21:03 | <shu> | yet c++ is faster. curious |
| 21:04 | <snek> | maybe you're on to something here |
| 21:04 | <snek> | kevin can you disable all the lint rules in ecmarkup |
| 21:05 | <bakkot> | jugglinmike pointed me to the commonmark tspec the other day https://spec.commonmark.org/0.30/ |
| 21:05 | <bakkot> | which is similarly... difficult to mechanize, let us say |
| 21:06 | <bakkot> | incidentally my dad contributed to the C++ spec; the very first paragraph of any specification I ever read was this one: https://timsong-cpp.github.io/cppwp/n4861/temp.expl.spec#8 |
| 21:07 | <bakkot> | which is, in fairness, deliberately opaque |
| 21:07 | <bakkot> | it is deliberately opaque so that people won't read the last line, which is a limerick |
| 21:07 | <snek> | oh my god |
| 21:08 | <shu> | i am mostly appreciating that comments in code listings are in proportional serif? |
| 21:11 | <snek> | i guess this technically is a proportion https://gc.gy/134437262.png |
