For precedence and associativity annotations, we adopt non-linear visibility, that is, they are visible in the whole enclosing basic specification. This is mainly to ease parsing and follows the rules for mixfix declarations, see [CoF99], comment to App. C-3, page C-7.
Precedence annotations interact with structured specifications in the same way as the subsorting relation. That is, for renamings and restrictions, the precedence relation is lifted along the renaming or restriction. For unions and extensions, the precedence relations are united. Note that in the case that there are conflicting precedence annotations this may lead to equivalent symbols in the union. In this case these symbols cannot be combined without explicit grouping. As an example take a specification SP1 with the precedence __+__ < __*__ and a specification SP2 with the precedence __*__ < __+__. In the union of SP1 and SP2 the operations __+__ and __*__ are equivalent, i.e. 3 + 4 * 5 becomes ill-formed in the union, though it is well-formed in both SP1 and SP2.
Associativity annotations are translated along renamings and restrictions and united along unions and extensions in a similar way.