Re: Multitype support in bison

[Ilyes Gouta]

Hi Laurence,

> It's up to you.  I don't think it's a good idea to use different types for
> the semantic value of a single symbol; `expr', in your example.  Does this
> work?  It wouldn't have occurred to me to try it.

It barely works. So are you suggesting that I keep a unified set of
rules and do the differentiation at the action level?

If I do so, and knowing that I have to handle both int(s) and float(s)
in my scripts, then the .y file would contain something like:

%union {
    int val; // the content of the variable
    char* id; // the name of the variable
}

where val is used to hold an int, i.e the value of an identifier which
*also* can be a float! Knowing that sizeof(int) == sizeof(float) on
current x86, that would be possible using some dirty C statements
(accessing val using properly casted pointers to the desired type).
All this, for me, seems to be a the natural consequence to the usage
of the unified set of rules for both types. What happens if I have to
add support for doubles?

> or `double' (depending on the value of a preprocessor macro).  The 3DLDF
> grammar has a token `INTEGER' whose semantic value is `int', but it is
> replaced by a `float' or `double' in the "chain" of actions that "turn it
> into" a `numeric_<something>'.

I guess this is to pick up the right action when the parser has to
deal with operations such as adding a float to an int.. so that the
chain morphs to the right combination.. Am I right?

> I hope I'm not overstepping the bounds here, but an idea that I would like

Actually, it's pretty interesting :)

> to suggest is that you not write a C-like language.  There must be
> thousands of them by now.  It's a typical homework assignment for people
> studying computer science.  There are plenty of languages waiting to be
> written with Bison that would really be useful.  It would be a shame to
> write yet another "Appendix A" language.

Well, actually I'm planning to write a JIT'ed version for my
simplified C-like language where the parser emits native opcodes
instead of just interpreting the script.

Waiting for your answer!

BR,
Ilyes Gouta.