| 16:07 | <Michael Ficarra> | shu: for the reason bakkot stated: we don't have a need to support ad-hoc effects |
| 16:07 | <Michael Ficarra> | we will always know all the effects we support |
| 16:07 | <Michael Ficarra> | something like that is more appropriate as separate attributes than crammed into a comma-separated string together |
| 16:08 | <shu> | what do you want to be in the dd? |
| 16:08 | <shu> | just empty? |
| 16:08 | <shu> | i mean it could also be a known list of effects in <dt>effects</dt> |
| 16:09 | <Michael Ficarra> | they're 2-state, right? so true/false? |
| 16:09 | <shu> | well, and absence |
| 16:09 | <shu> | i don't see a lot of gains for separate attributes other than more typing |
| 16:10 | <shu> | but i see the argument about not having it be arbitrary |
| 16:51 | <bakkot> | yeah, I guess I would lean towards having it be a single attribute, for the sake of ease of reading/writing |
| 16:51 | <bakkot> | if we want to limit the allowable values we can enforce that with the linter |
| 17:00 | <Michael Ficarra> | separate attributes is easier for scripting |
| 17:00 | <Michael Ficarra> | otherwise every scripting operation needs to do the field parsing too |
| 17:00 | <bakkot> | that seems like it should be a very low priority |
| 17:01 | <bakkot> | speaking as the person who does most of the maintenance of the scripting here |
| 17:27 | <shu> | the scripting is .split(',')? |
| 18:19 | <shu> | i saw you ran an autoformatter, what should i be running? |
| 18:19 | <shu> | bakkot: |
| 18:21 | <bakkot> | npm run format |
| 18:21 | <bakkot> | also re: "static sdo", it's not enough to just update 262; ecmarkup knows about a specific list of types |
| 18:22 | <bakkot> | which does not include "static sdo" |
| 19:04 | <shu> | i saw that there was special handling for some |
| 19:05 | <shu> | what additional things does ecmarkup need to be taught about static sdos, if the only thing that needs static sdo handling is the effect propagation? |
| 19:11 | <bakkot> | I think you can just grep for 'sdo' in header-parser.ts, but like I said I think it would be better to track that as a separate bit rather than putting it into "type" |
| 20:44 | <shu> | fair enough |
| 21:03 | <bakkot> | also I think you can get away without changes to 262 - you can just rely on the "Static Semantics" prefix, no? |
| 21:38 | <ljharb> | for step 10 of https://tc39.es/ecma262/#sec-string.prototype.lastindexof - is there any interest in me restating that prose in the form of an explicit loop? (like how it's done in https://tc39.es/ecma262/#sec-stringindexof) |
| 22:10 | <shu> | bakkot: yes, good point, "Static Semantics" prefix suffices |
| 23:38 | <bakkot> | ljharb: yes, that sounds great |
| 23:38 | <bakkot> | the proposal copied what was in StringIndexOf before https://github.com/tc39/ecma262/pull/2258 landed, I suppose |
| 23:38 | <bakkot> | wish I'd noticed that during review |
| 23:39 | <bakkot> | or, wait |
| 23:39 | <bakkot> | I'm thinking of find-from-last |
| 23:39 | <bakkot> | lastIndexOf is old |
| 23:40 | <bakkot> | anyway, yes, such a PR sounds great; I would have done it in 2258 if I'd noticed |
| 23:43 | <ljharb> | Great! do you prefer an inline algorithm, a separate AO, or making StringIndexOf two-way via an arg? |