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
Currently all postfix operators have higher precedence than prefix operators. This has some unfortunate limitations though:
// Postfix increment in expression statement. Fails to compile.
// because it is evaluated as <:(hl++), which is not a permitted expression statement.
// Also because of precedence, it also currently implies a higher-bit increment followed by bit-masking.
<:hl++;
// Postfix increment in assignment right-hand side. Also fails.
// Similar to above parse, but different restrictions.
// It tries to decompose <:(hl++) into:
// a = hl; a = <:a; hl++; which will not work.
a = <:hl++;
++<:hl; // Prefix increment. Works fine.
a = ++<:hl; // Prefix increment. Works fine.
See if there's some way that the compiler can instead bind the unary prefix access operators with less precedence than incrementation (eg. by manual fix-up during parsing). Most of the time, we want normal prefix operator precedence rules, but post-incrementation is an exception.
Short of some other ambiguity, it would be nice to make <:expr++ always mean (<:expr)++ and not >:(expr++) so it has more useful semantics.
NOTE: these uses should continue to work:
// becomes a = l; due to register decomposition.
a = <:hl;
// take the low-byte of an address literal.
a = <:&myaddress;
// constant indexing, so the address can be folded at compile-time, and then <: masks off
a = <:word_array[0]
// take the low-byte of some indirected larger-than-byte thing (if the platform were to allow it)
foo = <:*term;
The text was updated successfully, but these errors were encountered:
Currently all postfix operators have higher precedence than prefix operators. This has some unfortunate limitations though:
See if there's some way that the compiler can instead bind the unary prefix access operators with less precedence than incrementation (eg. by manual fix-up during parsing). Most of the time, we want normal prefix operator precedence rules, but post-incrementation is an exception.
Short of some other ambiguity, it would be nice to make
<:expr++
always mean(<:expr)++
and not>:(expr++)
so it has more useful semantics.NOTE: these uses should continue to work:
The text was updated successfully, but these errors were encountered: