The table is correct, and the examples are wrong.
: The relevant parts of S03 are:
: Junctive operators
: 1|2|3 + 4; # 5|6|7
: 1|2 + 3&4; # (4|5) & (5|6)
: multiplicative * / % x xx +& +< +> ~& ~< ~>
: additive + - ~ +| +^ ~| ~^
: junctive and (all) &
: junctive or (any) | ^
: (1|2|3) + 4 => 5|6|7 but if + is higher precedence than |
: 1|2|(3 + 4) => 1|2|7
: pugs produces 1|2|7 currently, in keeping with S03
: In this case is seems like raising junctive ops higher would
: be correct, but there more to it?
We spent a goodly long time discussing this very topic in one of our
design meetings. The intent of junctions is primarily to produce
superposed data values, not to make it possible to write impenetrable
code, so the question boils down to whether operators like "+" are
used more often to build the sorts of data values you'd want to "|",
or whether "|" is used to build junctions that you'd want to "+".
We decided that the examples like
1|2|3 + 4; # 5|6|7
1|2 + 3&4; # (4|5) & (5|6)
were in fact highly artificial, and people would much more often
be using simple operators to compose alternative values:
$a + 1 | $a - 1
That was our gut-level feeling. A lot of this design stuff comes down
to just that. So we could be completely and utterly wrong about it.
Examples are now fixed in S03.pod in the svn repository.