Re: Stack Info or subparsing?

[Adam Smalin]

Lets say I do want to do it in Flex (is that a separate mailing list?)
actually, I can't ONLY do it in flex. Unless I want a C like #define.
I need some way of balancing {([ and anything else that opens/close.
Also I need to ensure I don't end in an invalid state like int a =. I
wouldn't want something like `blah var` to be allowed. That would be
confusing. You don't know if its declaring var or doing something
else.

But anyways I can't only do it in flex as I need to balance braces and
others out. Doing @start blah int a=1; } @end would certainly allow me
to compile `class A { blah ...` which would be confusing as heck and
is still balanced because '}' is in the blah body.

I just tried grabbing the state and i think i found the lex state
rather then bisons. I think if i just copy the pointer or make a
pointer to pointer of yystackp I can simply do yystackp->yyspaceLeft
to check if space left matches. I tested by putting a breakpoint on //
(comment) and using my debugger (MSVC) to go back to yyparse and
looked at the variable. So I guess I got depth solved I now need state
so the @end could check if it matches or makes sure it ends at a valid
location.

Where is bison state? Nevermind I just looked. #$%^&*($%^& Theres two
loops, one for deterministic the other one not. I do need %glr-parser
so... damn. Hmm, function body is not ambiguous but maybe two
ambiguous can pass by that... I guess I cant cheat by looking at any
global state bc it may not be used or may be changed. Hmmm. Big
downside to checking state.

Has anyone done anything with checking state? Akim said my grammar is
_very_ large so its not like making a parse rule that allows function
and class level declarations will be easy. I'd need to cut things out
I can allow if to be parse and throw an error if it happens to be in
class level but there was some syntax that cause many conflicts so I
didn't allow it in body. Hmm I cant remember what it was ATM

On Thu, Oct 11, 2012 at 10:55 AM, Akim Demaille <address@hidden> wrote:
>
> Le 11 oct. 2012 à 16:46, Adam Smalin a écrit :
>
>> hmm, I never thought about just building it with bison and including
>> it later (so no input).
>> 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.
>
> It looks like a _very_ large grammar.
>
>> 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
>
> You still have not explained if parsing inside @start/@end is wanted
> or not.  If it is not, then these questions are not related to
> Bison, but for instance to Flex.  In that case, have a look at
> start conditions, and to functions such as yy_push_state.  Or just
> deal with counters.
>
> I don't understand what you mean by "check state and stack".  You're
> not expected to check the state and stack of your parser at runtime
> (unless you mean reading the *.output file), that the parser's business.
>