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.
_______________________________________________
[email protected] http://lists.gnu.org/mailman/listinfo/help-bison
