[Feature] Provide handler to support non-returning states [sf#24]

[lsf37]

*Reported by anonymous on 2010-10-17 12:10 UTC

In the lexer you often return the new state, but that's not required. I'd like to be able to catch all cases. Those who return a state are easy to catch, the others not.

If would be nice to add something like

%defaultreturn {
%defaultreturn }

where you can add some lines of code if it's not returned during the switch it should be placed right after the switch, so

switch (zzBufferL[zzCurrentPosL]) {
//a lot of cases and a default
}
/* include lines of defaultreturn here */

[lsf37]

Commented by rfscholte on 2010-10-23 09:02 UTC And/or a try/finally statement around the switch to catch them all, no matter what. Only with one of these solutions I will be able to catch them all.

To give an idea why we need such solution: we're working on a streaming parser, which means we'll write while reading to keep the output as much as the same as the input. While writing we want to use eventhandlers to select certain states to slightly modify them. Untill now we parsed the input to a model and wrote that to a file, but this way some data might get lost (comments, indents, etc.). That's why we need to catch every loop.

example :

try {
  switch (zzBufferL[zzCurrentPosL]) {
     //a lot of cases and a default
  }
}  finally {
    %statehandler%
}

[lsf37]

This can already be implemented by either always returning something in each action or by calling a method that does some default action in each method. I.e. the feature may add convenience in some cases, but does not change expressivity.

In terms of convenience, actions that ignore input tend to be rare -- usually you do want to do something with the input and for cases where the action becomes repetitive, there is already the | action to group expressions together.

Overall, I don't think increase in convenience justifies another language feature.