hmm, I never thought about just building it with bison and including it later (so no unput). The only issues I see is I will need to force the user to specify if it should be function, class or namespace level. It may be a lot of work to make another set of rules that is all levels. I already have >1K lines (look like 1300 lines of rules. I'm counting between the two %%) but I think I'll give it a try if it will make this higher quality.
I'd still like to know how I can check state and stack in case its easier to do that. I'm relooking at the code and the conflicts On Thu, Oct 11, 2012 at 9:27 AM, Akim Demaille <[email protected]> wrote: > > Le 11 oct. 2012 à 15:20, Adam Smalin a écrit : > >> Lets say I want to do something like this >> >> @Start Blah >> int a,b >> void func() { >> beep() >> } >> float c >> @end >> >> Then I will use Blah in place of declaring all that. Kind of like a C >> define. Now here is the twist >> >> @Start Blah >> int a,b >> void func() { >> beep() >> >> float c >> @end >> >> I want this to fail because it doesn't end in the same scope. Doing } } >> should fail as well as it end one scope to many. >> What is the best way to implement this? I believe I can use unput when I >> see Blah but the problem is ensuring the same scope. If I do it in multiple >> code blocks I believe ending to little or many would still have the parser >> in the same state so I can't simply look at state. I'd need a way to look >> at the stack AND state. An easy hack would be to count '{' and '}' however >> that will not work because what if i ended it with float c=. >> >> So my question is how do I look at the state so I know it wasn't ended at >> something like '=' (theres not that many valid states to do this. I believe >> only in the body of namespace, function and class). How do I look at the >> stack to know if I am in the right depth? > > You seem to hesitate between dealing with this at the scanner > level (hence your words "state", "stack", "unput" etc.), and doing it > at the level of the parser (in which case this is trivial, > just write your grammar, it will work). > > If you just want to balance the braces between @start and @end, > then doing it with Flex seems the right things, and just count > the braces. If the content of @start/@end is well defined, and > should be controlled, then do that with Bison, and trust it: > it won't accept improperly balanced input. > _______________________________________________ [email protected] https://lists.gnu.org/mailman/listinfo/help-bison
