Dear Konrad, the answer to your question is : it isn't pssoble as is in SmaCC (it breaks the underlying tcomputation heory). In practice, there are various ways to do so, depending on the kind of grammar you are building (and whether or not your grammar has conflicts). Cleanest way is to do a check at the end of the action (check that all <opidentifiers> are equal in the action, reject if this is not the case). You can use, if your grammar has conflicts, the GLR mode and select the right interpretation or reject the input. Another approach is to change the state of the scanner based on your actions, and so trigger the right production rule by emitting different tokens for example (such as a <sameOpIndentifier> following an <opIdentifier>. Again, different ways to do that; SmaCC offers an easy path to scanner specialisation that is fully compatible with SmaCC code generation (i.e. no fear to loose your customisation). Hope this helps, Thierry Le lun. 23 mai 2022 à 01:01, Konrad Hinsen <konrad.hinsen@fastmail.net> a écrit :
Hi everyone,
I am stuck with a problem in SmaCC (of which I am a newbie user). Hoping for suggestions from experts, any kind of pointer is welcome!
I have a production rule for infix operators:
Term : NonInfixTerm 'arg' (<opIdentifier> 'opName' NonInfixTerm 'arg') * {{InfixOpTerm}} | NonInfixTerm ;
According to the syntax rules of my language, infix terms are valid only if all <opIdentifier>s are equal. Otherwise parentheses must be used to disambiguate, as the language has no precedence rules.
How can I do this with SmaCC? I don't see how I could do it using the basic features, but maybe with some tweaking on the Pharo side.
Thanks in advance, Konrad.