[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Factor %FLAG at scan level.

From: Akim Demaille
Subject: Re: [PATCH] Factor %FLAG at scan level.
Date: Fri, 10 Apr 2009 15:27:46 +0200

Le 9 avr. 09 à 06:48, Joel E. Denny a écrit :

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.

So let's go for parse.assert and parse.trace.

I would prefer:


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.

Or maybe we should use the value, like you did for the api. As you noted, it doesn't make sense with other api related things, such as %pure. %define lex.api symbol|pure|global? Or api.lex.

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:


But people aren't going to like typing that.  Maybe:


This appeals to me, but maybe others find it ugly. I can live with just

I prefer "locations".

- %define variant (, and 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

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

It should be easy to port the code.

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);
      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.

I agree.  Will change that.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]