reminds me of ssyntax's strict evaluation rules. I might have been tempted at some point to treat this as meaning the third zip code of the fifth address, thinking in error that . had higher precedence than !. Force of habit from arithmetic expressions with a similar shape, e.g.
a + b / c + d
In ssyntax, everything is evaluated from left to right regardless of the operator.
In ssyntax, everything is evaluated from left to right regardless of the operator.
Actually, no. . and ! are evaluated left-to-right in relation to each other, but there are currently three priority levels; from highest to lowest they are: (1) : and ~, (2) . and !, (3) &. Characters within the same level needn't be evaluated left-to-right, though . and ! are. For example,
arc> (ssexpand 'a.b:c.d) ; : takes precedence over .
(compose a.b c.d)
arc> (ssexpand 'a.b&c.d) ; . takes precedence over &
((a b&c) d)
arc> (ssexpand 'a:b&c:d) ; : takes precedence over &
(compose a b&c d)
Then, since & has lower precedence than ~, you can't do
arc> even&~odd
which causes Arc to hang (which is actually a bug).
Further, though ~ and : are in the same level, : takes priority over ~ regardless of order.
arc> (ssexpand '~a:~b)
(compose (complement a) (complement b))
If you're interested in rewriting code to use ssyntax, you can check out my sscontract library (and let me know if it's broken!): http://arclanguage.org/item?id=11179
