Editorial: some abstract operations are incorrectly labeled as "Runtime Semantics:"

[domenic]

This might be me not understanding a convention in use. But there are a lot of sections which are labeled "Runtime Semantics:" which don't correspond to a grammar element, and in fact are abstract operations, not grammar semantics.

Examples: GetSuperConstructor; MakeSuperPropertyReference; AllocateTypedArray; EvaluateDirectCall.

I think a search for Runtime Semantics: ([^(]+)\( will find most of these.

[bterlson]

Abstract operations are most likely runtime semantics, but may not necessarily be. An abstract operation that doesn't depend on any runtime state would be static semantics.

That said, since Runtime Semantics is the default half the time anyway, I plan to remove every "Runtime Semantics: " qualifier and add some verbage around how abstract operations are static semantics if prefixed with "Static Semantics: ", and otherwise are runtime semantics. I'll leave this issue open to track that work :)

[bterlson]

Abstract operations are most likely runtime semantics, but may not necessarily be. An abstract operation that doesn't depend on any runtime state would be static semantics.

That said, since Runtime Semantics is the default half the time anyway, I plan to remove every "Runtime Semantics: " qualifier and add some verbage around how abstract operations are static semantics if prefixed with "Static Semantics: ", and otherwise are runtime semantics. I'll leave this issue open to track that work :)

[domenic]

Hmm OK. I thought there was some division between "semantics" which were tied to grammar productions, and "abstract operations" which took argument lists and were called.

For example, "semantics" can appear multiple times ("Runtime Semantics: Evaluation" appears several times for example) whereas abstract operations are only defined once.

[domenic]

Hmm OK. I thought there was some division between "semantics" which were tied to grammar productions, and "abstract operations" which took argument lists and were called.

For example, "semantics" can appear multiple times ("Runtime Semantics: Evaluation" appears several times for example) whereas abstract operations are only defined once.

[bterlson]

I also thought that, but @allenwb clarified for me.

For the Evaluation case, you can consider the abstract operation as a method on the production rather than a particular name (aoid) in the global spec namespace.

[bterlson]

I also thought that, but @allenwb clarified for me.

For the Evaluation case, you can consider the abstract operation as a method on the production rather than a particular name (aoid) in the global spec namespace.

[domenic]

Hmm OK. So should things like "Evaluation" or "Early Errors" get parenthesis ("Early Errors()") if they are abstract operations?

[domenic]

Hmm OK. So should things like "Evaluation" or "Early Errors" get parenthesis ("Early Errors()") if they are abstract operations?

[bterlson]

Yes, and further, parameters should be moved into the signature with the prose descriptions removed (unless they clarify the expected type of those parameters).

[bterlson]

Yes, and further, parameters should be moved into the signature with the prose descriptions removed (unless they clarify the expected type of those parameters).

[zenparsing]

That reminds me, I think we could improve the language surrounding these closures/anonymous built-in functions...

[zenparsing]

That reminds me, I think we could improve the language surrounding these closures/anonymous built-in functions...

[bterlson]

@zenparsing tell me more!

[bterlson]

@zenparsing tell me more!

[zenparsing]

Oh, I didn't have a specific solution in mind, but the specification of closures (like Promise Resolve Functions) is pretty awkward. I ran into a lot of this when spec'ing Observable. For one, the argument lists of these functions are always buried in prose.

[zenparsing]

Oh, I didn't have a specific solution in mind, but the specification of closures (like Promise Resolve Functions) is pretty awkward. I ran into a lot of this when spec'ing Observable. For one, the argument lists of these functions are always buried in prose.

[bterlson]

I think I can close this. If someone wants another issue to track removal of Runtime Semantics: across the entire spec, have at it. This title confuses me now though :)

[bterlson]

I think I can close this. If someone wants another issue to track removal of Runtime Semantics: across the entire spec, have at it. This title confuses me now though :)