-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ECMA262 completion records are not interpreted appropriately #518
Comments
The first solution that comes to mind is for Infra to define a macro-like shorthand named "throw if abrupt". It could look something like this:
And here's how it could be used to correct "serialize a JavaScript value to a JSON string": -1. Let result be ? Call(%JSON.stringify%, undefined, « value »).
+1. Let result be Call(%JSON.stringify%, undefined, « value »).
+1. Throw if abrupt given result.
1. If result is undefined, then throw a TypeError.
1. Assert: result is a string.
1. Return result. |
The "?" operator appears about 60 times in HTML (the simple search query includes some false positives):
In addition to the semantics problem detailed in this issue's description, neither Infra nor HTML explain what "?" means. WebIDL is more explicit in its application of "?", annotating each use with a reference to the definition in ECMA262.
WebIDL also indirectly explains the operator by explicitly adopting the algorithm conventions of ECMA262. Unfortunately, it does this by making some inaccurate statements about the relevant semantics:
With all this in mind, here's a variation on the solution I suggested above:
Generally, I'd prefer to use a distinct algorithm name in order to avoid confusion, especially for an esoteric shorthand like "?". One issue with that is the amount of churn it would involve (using "throw if abrupt" or similar would involve splitting algorithm steps apart). I think overriding the operator might work in this case, though. The proliferation of this problem suggests that folks are tacitly performing the translation on their own. In that respect, overriding the operator for web specs just closes a loophole for folks who are new to this work and for those who are scrutinizing the boundaries with ECMA262. |
I like the idea of linking |
I agree with the problem statement, and the 5-step approach sounds good. However, the problem of completion records is a bit bigger:.
|
Thanks, @jmdyck! As a fourth possibility about asserting normal completions, could we consider just referencing ECMA262's definition of "!" directly? As I understand the semantics, they already seem coherent from the perspective of WHATWG conventions. |
Yup, that too. |
ECMA262 uses a control flow convention built on completion records--"wrapper" values that the standard's macro-like shorthands (e.g. ReturnIfAbrupt and the question mark symbol) use to conditionally halt algorithms.
The effect is similar to the notion of "exception throwing" in web specifications, but the mechanism is fundamentally different. This means that fallible ECMA262 algorithms cannot be interpreted identically in web specs.
For instance, consider "serialize a JavaScript value to a JSON string" in Infra
According to the definition of the
?
shorthand, the first step either stores a value in "result" or causes this algorithm to return a "throw" completion record. Combining those possibilities with the following steps means that the algorithm can have one of three results: returning a "throw" completion record, throwing an error, or returning a string.In ECMA262, the first two are different ways of saying the same thing, but that isn't the case in web specs. We can see this in the call site of the algorithm described above:
Were this written in ECMA262, that invocation would likely be preceded by the
?
symbol. The Infra standard probably omits it because web specifications rely on exception throwing semantics. However, the effect is that the value of the variable named "string" may be a "throw" completion record.Although there are only three instances of the
?
operator in Infra, I'm told that this pattern also shows up in HTML and in WebIDL, so I'm reporting this issue to start a discussion about the best way to address the problem.The text was updated successfully, but these errors were encountered: