bison-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] Use variants to support objects as semantic values.


From: Akim Demaille
Subject: Re: [PATCH] Use variants to support objects as semantic values.
Date: Tue, 4 Nov 2008 21:02:58 +0100


Le 4 nov. 08 à 11:50, Paolo Bonzini a écrit :

I just say that the java skeleton now uses %define stype, which is

s/say/saw/

correlated.  I regret that the names were not discussed first, now we
face a lack of structure, although Joel had been careful up to now to
propose something consistent.

"%define stype" goes with "#define YYSTYPE" in C/C++; it was introduced
before dotted names were introduced for %defines.  Note that it is in
principle possible to move from "#define YYXYZ" to "%define xyz" for
this and other preprocessor macros in the C/C++ skeletons.

I really want to get rid of the CPP directives in favor of Bison directives. And I'd like that we continue getting rid of specific directives such as %debug to move into a more consistent %define debug style. It has the added value that then it then automatically benefit from --define (which is somewhere waiting to the pulled from the candidates/make-symbol branch) which saves us from inventing a bazillion of new options (--locations, --debug etc.), documenting them twice (once as a directive, and then as an option) etc.

Of course backward and yacc compatibilities have to be considered.

What about doing like this:

1) %union => use unions

Makes sense :)

2) %define stype => use given type as ::semantic_type

I really dislike stype, it looks like (verbose :) assembly language.

3) no %union, no %define stype, b4_tag_seen_flag=1,
%define global_tokens_and_yystype => do not define YYSTYPE at global

I guess this is not what you meant here.

scope, and use YYSTYPE as ::semantic_type

4) no %union, no %define stype, b4_tag_seen_flag=1,
no %define global_tokens_and_yystype => use variants

5) no %union, no %define stype, b4_tag_seen_flag=0
=> use int as ::semantic_type

?

I have once been fond of such cascading rules, but it turned out it was too complex to be easy to teach. I guess I would rather have something like

%define semantic.type.kind union|variant|type
// in the latter case
%define semantic.type.value  USER-DEFINED (defaults to int or YYSTYPE)

%union would %define semantic.type.kind union

Or maybe use impossible values ?

%define semantic.type "%union" or "%variant" or "USER-TYPE".



reply via email to

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