[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multitype support in bison
From: |
Ilyes Gouta |
Subject: |
Re: Multitype support in bison |
Date: |
Sat, 13 Oct 2007 15:24:31 +0200 |
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.
- Multitype support in bison, Ilyes Gouta, 2007/10/12
- Re: Multitype support in bison, lfinsto1, 2007/10/13
- Re: Multitype support in bison,
Ilyes Gouta <=
- Re: Multitype support in bison, Claudio Saavedra, 2007/10/13
- Re: Multitype support in bison, Ilyes Gouta, 2007/10/13
- Re: Multitype support in bison, Laurence Finston, 2007/10/14
- Re: Multitype support in bison, Ilyes Gouta, 2007/10/14
- Re: Multitype support in bison, Ilyes Gouta, 2007/10/14
- Re: Multitype support in bison, Laurence Finston, 2007/10/14
- Re: Multitype support in bison, Laurence Finston, 2007/10/14
- Re: Multitype support in bison, Ilyes Gouta, 2007/10/14
- Re: Multitype support in bison, lfinsto1, 2007/10/15
Re: Multitype support in bison, Hans Aberg, 2007/10/14