Re: Stack Info or subparsing?

[Adam Smalin]

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 <address@hidden> 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.
>