[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Factor %FLAG at scan level.
From: |
Joel E. Denny |
Subject: |
Re: [PATCH] Factor %FLAG at scan level. |
Date: |
Thu, 9 Apr 2009 00:48:43 -0400 (EDT) |
On Wed, 8 Apr 2009, Akim Demaille wrote:
> > Maybe we should go ahead and rename api.push_pull and
> > lr.keep_unreachable_states in 2.5.
>
> There's some ambiguity here: do you mean to make - vs. _ indifferent,
> or simply move to using - ? I first thought about normalizing _ into
> -, but afterall I prefer a single name.
I mean move to using "-".
> > Ironically,
> > we didn't think of a good namespace for namespace.
>
> Why not 'api.'?
Sounds good.
> > These all describe different aspects of the run-time parser behavior.
> > Maybe they should be:
> >
> > parse.assert
> > parse.debug
> > parse.error-verbose
>
> Good with me.
>
> > Is assert too general? Will there ever be other kinds of parser
> > assertions that should be controlled independently?
>
> I don't think we should go too much in the details. Maybe I should
> have put it into api.debug, but it incurs some speed penalty, while
> api.debug does not (or almost) and can be left active in production
> parsers, while, IMHO, assert should not.
Ok.
> BTW, I would prefer api.trace ove api.debug for %debug. No big deal.
> And then, maybe %api.debug to be what I called %api.assert.
Are you intending to write api.debug and api.trace? Or do you mean
parse.debug and parse.trace as above?
I like both trace and assert better than debug, which is very vague.
> > I would prefer:
> >
> > api.lex-symbol
>
> I really am not happy with "lex-symbol", but if you can't do better, I
> certainly can't :)
Other than the new prefix, I have nothing so far.
> >> - %define locations
> >> %locations
> >
> > This makes an api change and adds a new task to the parse, so I'm
> > not sure
> > any specific namespace is appropriate.
Then again, the api change is secondary. The real point is to request
that locations be tracked during parsing.
> So maybe it should be a namespace per se. People (I know some) would
> certainly appreciate more control over the types used here.
> It's already using %define filename_type to be told... the type of the
> filename field, and a hidden control to specify whether we want ctors
> or not (as it forbids them from being included in unions).
Makes sense. We could have nested namespaces:
parse.locations
But people aren't going to like typing that. Maybe:
parse.locs
This appeals to me, but maybe others find it ugly. I can live with just
"locations".
> >> - %define variant (lalr1.cc, and glr.cc in my branch)
> >> Use variants instead of union.
> >
> > Maybe use "variants" for consistency with "locations". That fits the
> > phrase "use variants". Is it appropriate to think of this as an api
> > change?
>
> Well, that depends what you call "api": AFAIR it does not change
> anything to yylex/yyparse api
I was thinking of the generated code, so I'm not sure what the right
namespace is in this case.
>, but it does change the Bison API. For
> a start %type <> expects genuine types, no longer type tags bouncing
> to %union.
I remember we discussed this some time ago as we discussed make_SYMBOL and
modular grammars. Of course, I would like to see the same ability in C
skeletons.
> return yy::parser::make_TEXT ("I have three numbers for you.", loc);
> case 1:
> case 2:
> case 3:
> return yy::parser::make_NUMBER (stage, loc);
> case 4:
> return yy::parser::make_TEXT ("And that's all!", loc);
> case 4:
> return yy::parser::make_TEXT ("And that's all!", loc);
> default:
> return yy::parser::make_END_OF_FILE (loc);
> (Should the location be before the value in the make_SYMBOLs? It
> would probably look nicer.)
Somehow that does look nicer.
- Re: [PATCH] Factor %FLAG at scan level., (continued)
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/08
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/09
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/10
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/10
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/10
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/10
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/14
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/14
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/15
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/16
- Re: [PATCH] Factor %FLAG at scan level.,
Joel E. Denny <=
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/10
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/10
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/14
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/14
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/08
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/09
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/10
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/10
- Message not available
- Message not available
- Message not available
- Message not available
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/17