5.1.1Operators🔗 i

The set of recognized operators is:

• prefix-op : ++, --, +, -, ~, !

• infix-op : *, /, %, +, -, <, <<, >, >>, >>>, <=, >=, ==, !=, ===, !==, &, ^, \|, &&, \|\|

• postfix-op : ++, --

• assign-op : =, *=, /=, %=, +=, -=, <<=, >>=, >>>=, &=, ^=, \|=

For aesthetics and consistency with Scheme, some of the JavaScript operators with awkward or obscure operator tokens are given convenient synonyms in PJS:

• or = \|\|

• and = &&

• bitwise-and = &

• bitwise-ior = \|

• bitwise-not = ~

• bitwise-xor = ^

5.1.2Identifiers🔗 i

Identifiers in PJS (i.e., the id non-terminal in the grammar) are restricted to valid JavaScript identifiers. This ensures that, when generating actual JavaScript syntax, the exact name of a variable or object property is preserved, with no name mangling. (Since variable names are sometimes observable in JavaScript, this prevents subtle bugs where a program may change its behavior based on a particular mangling.)

5.2.1Disambiguating operators with #%keyword🔗 i

The following primitive operators have names that are valid JavaScript identifiers:

• and

• array

• begin

• block

• field

• label

• object

• or

• prefix

• postfix

• regexp

The parsing and code generation functions maintain an environment for lexically bound variables. JavaScript variable bindings can therefore shadow these operators. For example, in the expression

(function(array)

(return(array123)))

the inner occurrence of array is parsed as a variable reference rather than an array constructor.

Operators may be disambiguated with the use of the special form #%keyword. For example, (#%keyword. array) unconditionally refers to the initial binding of array, regardless of the current environment. The above example can then be rewritten as

(function(array)

(return((#%keyword. array)123)))

Note that if JavaScript code would dynamically bind one of these names (e.g., via with or eval), the operator is not shadowed, since the static environment only tracks lexical bindings.

5.2.2Disambiguating expressions with #%expression🔗 i

Expression statements introduce a few minor ambiguities into the PJS syntax. These include function declarations vs. named function expressions and if statements vs. if expressions. These are always resolved in favor of the declaration or statement form rather than the expression form, since in both cases the expression form is less likely to occur.

The expression form operator #%expression forces its argument to be parsed as an expression. For example, the expression (#%expression (if xyz)) is parsed as a conditional expression rather than a conditional statement.

5.3.1Java Dot Notation🔗 i

Similar to the Java Dot Notation originally introduced by JScheme, PJS permits the use of dotted identifiers as a short-hand for the obvious corresponding chains of object field references. Unlike in JScheme, it is impossible to bind a variable with a dot in its name, so dotted identifiers are always unambiguously decoded as field references.

For example, the identifier document.body.innerHTML is equivalent to the expression (field(fielddocumentbody)innerHTML).

5.3.2Multiary Operators🔗 i

Binary JavaScript operators are generalized in PJS to n-ary operators and expanded left-associatively into nested applications of the binary operator.

For example, the expression (- 4321) is equivalent to (- (- (- 43)2)1).

5.4.1S-expression Parsers🔗 i

5.4.2S-expression Generators🔗 i