You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are certain programs that are syntactically correct, but don't make much sense because they will raise an exception at run-time. One such example is having non-reference expressions (e.g. literals or arithmetic expressions or function calls) as targets of an assignment expression: those assignments are syntactically correct, but will raise a ReferenceError at run-time. So, while the parser cannot reject them, it could produce a warning.
Another example where warnings are beneficial is in case of function statements. Those are not in the spec but are acknowledged to be widely implemented. The implementations are recommended to either forbid the use of function declarations as statements or accept them with a warning (see http://es5.github.io/#x12).
Implementing this would likely warrant changes to the parser state as well as changing the parser interface to produce warnings. The changes are likely to be related to those required by issue #41.
The text was updated successfully, but these errors were encountered:
There are certain programs that are syntactically correct, but don't make much sense because they will raise an exception at run-time. One such example is having non-reference expressions (e.g. literals or arithmetic expressions or function calls) as targets of an assignment expression: those assignments are syntactically correct, but will raise a
ReferenceError
at run-time. So, while the parser cannot reject them, it could produce a warning.Another example where warnings are beneficial is in case of function statements. Those are not in the spec but are acknowledged to be widely implemented. The implementations are recommended to either forbid the use of function declarations as statements or accept them with a warning (see http://es5.github.io/#x12).
Implementing this would likely warrant changes to the parser state as well as changing the parser interface to produce warnings. The changes are likely to be related to those required by issue #41.
The text was updated successfully, but these errors were encountered: