Table interactions should be driven by operations rather than prose

[gibson042]

ECMA-262 uses a wide variety of patterns when referencing tabular data—implicitly, by column ordinal position, by [quoted or unquoted] column name, etc. Some examples:

• ToBigInt: "Return the value that prim corresponds to in Table 14."
• CreateIntrinsics: "Set fields of realmRec.[[Intrinsics]] with the values listed in Table 6. The field names are the names listed in column one of the table."
• OrdinaryFunctionCreate et al.: "Let internalSlotsList be [the list-concatenation of « … » and] the internal slots listed in Table <number>."
• Evaluation of typeof: "Return a String according to Table 41."
• ApplyStringOrNumericBinaryOperator: "Let operation be the abstract operation associated with opText and Type(lnum) in the following table"
• UnicodeMatchProperty: "Assert: p is a Unicode property name or property alias listed in the “Property name and aliases” column of Table 68 or Table 69… Let c be the canonical property name of p as given in the “Canonical property name” column of the corresponding row."
• TypedArray: "Let constructorName be the String value of the Constructor Name value specified in Table 71 for this TypedArray constructor."
• NumericToRawBytes: "Let n be the Element Size value specified in Table 71 for Element Type type.… Let convOp be the abstract operation named in the Conversion Operation column in Table 71 for Element Type type."

I think it would be better (and probably friendlier to esmeta) to introduce operations for accessing them more consistently. A sketch from tc39/proposal-temporal#2429 (comment) demonstrating use of hypothetical TableRows(table) and TableRow(table, columnNameByWhichToSelect, columnValue) operations:

-        1. For each row of <emu-xref href="#table-temporal-duration-record-fields"></emu-xref>, except the header row, do
-          1. Append the property name in the Property Name column of the row to _propertyNames_.
+        1. For each Record _field_ of TableRows(<emu-xref href="#table-temporal-duration-record-fields"></emu-xref>), do
+          1. Append _field_.[[Property Name]] to _propertyNames_.
         1. Let _sortedPropertyNames_ be SortStringsByCodeUnit(_propertyNames_).
         1. For each property name _property_ of _sortedPropertyNames_, do
           1. Let _value_ be ? Get(_temporalDurationLike_, _property_).
           1. If _value_ is not *undefined*, then
             1. Set _any_ to *true*.
             1. Set _value_ to ? ToIntegerWithoutRounding(_value_).
-            1. Let _fieldName_ be the field name named in the Field Name column in <emu-xref href="#table-temporal-duration-record-fields"></emu-xref> for Property Name _property_.
+            1. Let _field_ be TableRow(<emu-xref href="#table-temporal-duration-record-fields"></emu-xref>, [[Property Name]], _property_).
+            1. Let _fieldName_ be _field_.[[Field Name]].
             1. Set the field of _result_ whose name is _fieldName_ to _value_.

[syg]

We discussed this on the editor call. The editors don't feel strongly enough about making the phrasing for referring to specific cells / rows / columns consistent. The existing phrasing is fairly clear.

We also talked about how we'd like 262 to use tables. Our current position is that we like tables when used straightforwardly as lookup tables, which most of the use cases are. We want to discourage iteration of table data. For all the use cases you list here, we plan to specifically improve CreateIntrinsics and typeof (via #2915). All other uses seem good and we'd like to leave as-is.

[michaelficarra]

Closing in favour of #2953 and #2915.