Introduce a shorthand for ECMA262 abstract ops#539
Introduce a shorthand for ECMA262 abstract ops#539jugglinmike wants to merge 3 commits intowhatwg:mainfrom
Conversation
|
Would be interested in feedback from @jmdyck on this. |
|
As for the problems with defining |
|
Thank you, @jmdyck! I appreciate your encouragement to explain this more holistically. I couldn't find a way to expand the reasoning exactly according to the points you've outlined, but I hope the prose I've pushed up is sufficiently coherent, anyway.
Fair point. Those details don't seem necessary to explain the motivation or usage of this shorthand, though, so I've true to accommodate them simply by writing in less sweeping terms ("to model control flow interruptions such as thrown exceptions.")
After some more thought, I'm feeling like replicating 262's current (though imprecise) language still represents a meaningful step forward here. That said, I've also added a note to surface this consideration and help folks recognize when an improvement is available. |
Sounds good. |
|
@annevk I think this is ready for another look! |
annevk
left a comment
There was a problem hiding this comment.
How does this end up being different from JS's ? shorthand? This definition doesn't actually define anything as far as I can tell.
|
The difference is in the way that an abrupt completion is handled. In ECMAScript, it's simply returned (i.e., the algorithm using |
|
Thanks for the refresher. So I think what needs to happen is that we state that normatively. And then have an example that illustrates it. And not have the normative requirements be made through examples. |
This patch is in service of gh-518.
I've implemented this using the definition name "throw-if-abrupt" because I can't get Bikeshed to use
?(U+003F) as a name. If we think this might limit adoption, I can inquire about modifying Bikeshed.The new text (which I've largely copied from ECMA262) reduces ambiguity, but it does not eliminate it. There are ways of applying
?which do not match the example, even within Infra itself:...is not "otherwise equivalent to":
For what it's worth, ECMA262 suffers from the same deficiency, though some folks have been trying to address it. @annevk do you feel that the ambiguity undermines the goal of this patch?
Preview | Diff