Assume we have a cascade of phonological rules (or realisation rules) operating one after the other. It is sometimes more convenient to put them on the stack and compose with "compose net" rather than name each rule and use .o. (because one can easily change the order of the rules, which is iconic). Than one can use a construct like the following:
regex [..] -> a || .#.;
regex [..] -> b || .#.;
regex [..] -> c || .#.;
regex [..] -> d || .#.;
regex [..] -> e || .#.;
regex [..] -> f || .#.;
regex [..] -> g || .#.;
regex [..] -> h || .#.;
regex [..] -> i || _ .#.;
compose net
For a string x, these yields "xihgfedcba". The rules apply from the last declared to the first declared, which is the expected behaviour of the stack. If we want the rules to apply from top to bottom, as in most phonological (morphological) descriptions, it is necessary to change their ordering in the stack to the opposite with "turn stack".
So we have
regex [..] -> a || .#.;
regex [..] -> b || .#.;
regex [..] -> c || .#.;
regex [..] -> d || .#.;
regex [..] -> e || .#.;
regex [..] -> f || .#.;
regex [..] -> g || .#.;
regex [..] -> h || .#.;
regex [..] -> i || _ .#.;
turn stack
compose net
which should map "x" to "xabcdefghi", as it actually does in XFST.
However, in Foma we get "xahgfedcbi" instead. That is, only the last and the first network on the stack get swapped.
It should be noted that "rotate stack" does the same strange thing, instead of expected "xhgfedcbai" (this operation ought to move the top, i. e. last-added, element of the stack to the bottom).
Of course, it is always possible to name the rules, e. g. r1 r2 r3 ... and compose them in an explicit order with ".o.". However, when there are tens of rules in the grammar, it turns quite uncomfortable to rename them when rules are added in the middle or their order is changed, whereas non-iconic rule numbering (r1 .o. r4 .o. r2 .o. r3) seems rather error-prone.
I would be most grateful if this could be fixed, although surely workarounds (like naming and composing with a Python-script) are possible. I would be glad to fix it myself if only I had some C-programming experience...
Assume we have a cascade of phonological rules (or realisation rules) operating one after the other. It is sometimes more convenient to put them on the stack and compose with "compose net" rather than name each rule and use .o. (because one can easily change the order of the rules, which is iconic). Than one can use a construct like the following:
regex [..] -> a || .#.; regex [..] -> b || .#.; regex [..] -> c || .#.; regex [..] -> d || .#.; regex [..] -> e || .#.; regex [..] -> f || .#.; regex [..] -> g || .#.; regex [..] -> h || .#.; regex [..] -> i || _ .#.; compose net
For a string x, these yields "xihgfedcba". The rules apply from the last declared to the first declared, which is the expected behaviour of the stack. If we want the rules to apply from top to bottom, as in most phonological (morphological) descriptions, it is necessary to change their ordering in the stack to the opposite with "turn stack".
So we have
regex [..] -> a || .#.; regex [..] -> b || .#.; regex [..] -> c || .#.; regex [..] -> d || .#.; regex [..] -> e || .#.; regex [..] -> f || .#.; regex [..] -> g || .#.; regex [..] -> h || .#.; regex [..] -> i || _ .#.; turn stack compose net
which should map "x" to "xabcdefghi", as it actually does in XFST.
However, in Foma we get "xahgfedcbi" instead. That is, only the last and the first network on the stack get swapped. It should be noted that "rotate stack" does the same strange thing, instead of expected "xhgfedcbai" (this operation ought to move the top, i. e. last-added, element of the stack to the bottom).
Of course, it is always possible to name the rules, e. g. r1 r2 r3 ... and compose them in an explicit order with ".o.". However, when there are tens of rules in the grammar, it turns quite uncomfortable to rename them when rules are added in the middle or their order is changed, whereas non-iconic rule numbering (r1 .o. r4 .o. r2 .o. r3) seems rather error-prone.
I would be most grateful if this could be fixed, although surely workarounds (like naming and composing with a Python-script) are possible. I would be glad to fix it myself if only I had some C-programming experience...