The future

[Akim Demaille]

Hi People,

This mail is sent to the people who participate to the development of
Bison, and especially to Marc, Pascal and Robert who are at the origin
of most of the new stuff in Bison.  BTW, I'm referring to the trunk
only.

I'm looking for subscriptions, i.e., for people who will address one
of the following issues.  Keep us informed if you pick up a task.

1. %union

See my comment in the TODO file:

| * Prologue
| The %union is declared after the user C declarations. It can be
| a problem if YYSTYPE is declared after the user part.   []
| 
| Actually, the real problem seems that the %union ought to be output
| where it was defined.  For instance, in gettext/intl/plural.y, we
| have:
| 
|         %{
|         ...
|         #include "gettextP.h"
|         ...
|         %}
| 
|         %union {
|           unsigned long int num;
|           enum operator op;
|           struct expression *exp;
|         }
| 
|         %{
|         ...
|         static int yylex PARAMS ((YYSTYPE *lval, const char **pexp));
|         ...
|         %}
| 
| Where the first part defines struct expression, the second uses it to
| define YYSTYPE, and the last uses YYSTYPE.  Only this order is valid.

Someone should fix this. *And* immediately include a test case for
this.



2. The syntax for skeletons.

I like the original idea of Robert, but I think we didn't go far
enough.  How about this: instead of the complex

%%{section} %%{body} %%".c" %%{yacc}

Let's go to something like

%%{section, "%%{body}%%{tab}.c"}

or something along these lines.  The idea is basically to look right
now for a syntax which is more scalable and more uniform than above.
In the present case, body and tab are simple variables, tab being
`.tab' or `' depending upon the command line options.  This means
basically moving the handling of muscles from the scanner to the
parser.  I think it is the right move.

Of course there is the problem of whether Bison should look inside the
strings or not (I mean the scanner), which may lead us to use/not use
"" etc.  At least in this example, they don't appear to be required.




3. The selected outputs and backward compatibility and renaming.

I think the idea was originally by Marc, but maybe I misunderstood his
idea and ended up with the following.

How about a simple map of `name-by-default' -> `name-to-use'.  The
trick is that `name-to-use' ought to be null when something is not
wanted.  In other words, if %defines or --define is _not_ given, we
insert `y.tab.h -> 0' somewhere.

Or maybe, extend our %section into

%%{conditional-section, %%{body}%%{tab}.c, %%{defines}}

but there remains to handle the renaming.  I'm still dry on it :(

(Maybe have a look at GNU Make syntax).


4. The C++ output.

As you will sure have noticed, the pressure is still there for C++
output.  The skeletons we had almost 6 months ago are good.  It is
time to include this work in the current CVS Bison.  *Not* to debate
about their implementation (yet): we do not care about the actual
contents of the skeletons, what we want is a sound basis upon which we
can experiment and then discuss.  Of course it must ``work''.  Having
a Tiger C++ parser seems the least to ask.  But the main goal is to
make sure we have all we need to parse the skeletons, that we have all
we need in bison itself, not the C++ skeleton (for instance this will
probably require some mechanism to tell bison we are doing C++ from
the skeleton).

Then, later, when it works, we can improve the skeleton, and make sure
it pleases to the widest audience.

BTW, I still hope some of you have some sort of a state-of-the-art.
In particular, how Yacc++ etc. handle the various issues.




5. A Flex/Bison Scanner/Parser for the input file

This is not really hot topic, but really, sooner or later we will need
more primitives.  Several things come to my mind.

For a start, the $n notation is also widely criticized.  Many prefer

    exp (res): exp (a) '+' exp (b)
               { $res = $a + $b }

instead of

   exp: exp '+' exp
               { $$ = $1 + $3 }

Have a look at Robert's parse-skel section rule and you'll see why :)

Also, we need some means to free sometimes, the Bison parsers are
leaking a lot.  There are several options, which I hope to discuss
later, but one possibility is

%free exp { free ($$); }

etc.  Still more needs for easy extensions of the input syntax.




6. Introduction of a higher level in bitsets handling.

We need a type bitset_t or so with implementation of union,
subtraction, etc.  Maybe look if there is one available somewhere.
GCC comes to my mind: I know they have something for it.

Then, replace all the loops etc. in closure.c etc. into proper set
manipulations.




7. Err... I forgot.

Yet we have much to do :)