Editorial: Replace the operator tables with explicit steps #3002
Conversation
…r than operator Comprehension and visual comparison are easier when everything fits on one screen
|
Note that this reverses some of the directions of PR #1961:
See also PR #2945, which concluded with "the current editors all prefer the table" (in the semantics for |AssignmentOperator|). Not objecting, just making historical connections. |
|
Yeah I'm neutral on the table for compound assignment. But the change to the Number/BigInt operator dispatch is very nice! |
@jmdyck Much appreciated. This is indeed not even my first crack at this, let alone the first historical attempt. I did link to #2944 (whose rejection prompted the same fate for #2945) in the description, and both of them reference #1961. But even so, I feel like this form of the operations has legs.
@michaelficarra Thank you. The compound assignment table does have a simpler single-lookup-key structure, and is therefore less objectionable—my biggest issue is not its existence (I actually like tables, cf. #2944) but rather its placement inside an <emu-alg> step (cf.tc39/ecmarkup#513 (comment) ). If consensus is still to prefer it over text manipulation, then I would propose promoting it into a full <emu-table> at e.g. Assignment Operators or a new operation. Or yet another possibility would be introducing a new syntax-directed operation for |AssignmentOperator|. But the bottom line for me is that having it inside an algorithm step is unnecessarily awkward. |
|
@gibson042 we talked about this at the editor call today and couldn't come to an agreement. Personally I think the inline tables are the clearest option of those discussed, so I prefer the status quo. I am slightly negative on the algorithm steps which do string manipulation (since I think they require more thought to follow, plus the assert), and strongly negative on the algorithm steps which determine which AO to call (since I think they obscure what's going on, particularly since four of the 24 are different from the rest). But @michaelficarra was very positive about the second change. We'll talk about it a bit more next call, but unless we come to agreement we'll probably end up sticking with the status quo. |
|
We talked about this again and are happier with the status quo. We did discuss the option of factoring out the tables into their own steps, or introducing SDOs to do the parsing, but those both seem less readable. Thanks for the suggestion, though. |
The tables in Assignment Operators Evaluation and ApplyStringOrNumericBinaryOperator are somewhat redundant with each other, and the latter in particular is more complex than #2944 (comment) suggests to me is desirable (especially considering the resulting
_operation_(_lnum_, _rnum_)indirection), and incidentally are also the only examples of block-level elements inside an <emu-alg> step. I think they can be clarified and simplified by replacement with explicit algorithm steps.