Re: Multitype support in bison

[Laurence Finston]

On Sat, 13 Oct 2007, Claudio Saavedra wrote:

> 
> El s??b, 13-10-2007 a las 11:06 +0200, address@hidden escribi??:
> > It's a typical homework assignment for people
> > studying computer science. 
> 
> Hm, and maybe he is actually doing such a homework? :-)

More's the pity if he were.  That's one reason I'm glad I didn't study
computer science.  

On Sat, 13 Oct 2007, Ilyes Gouta wrote:

> Well, I'm doing it fun mainly. I'd like to experiment with JIT
> compiled code. 

JIT is "just-in-time"?  I don't know whether this fits in well with
GNU Bison in combination with C and/or C++.  However, it's not really
my area of expertise.  I associate this term more with Java.  One
thing I dislike about the field of Java (as opposed to the language in
the strict sense) is that the people who push it tend to gloss over
the fact that it's an interpreted language.  So the term
"just-in-time" kind of raises my hackles.  This isn't an argument
against it, of course.

> Is it possible to get an answer on my previous comment?
> :)

Yes, of course.  I'm usually pretty good about getting back to people, but 
I don't have a computer at home and otherwise have limited access to one.  
Sorry to keep you waiting.

On Sat, 13 Oct 2007, Ilyes Gouta wrote:

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

No, I was suggesting as _one_ possibility that you convert all
integers to floating point numbers.  I forgot to mention that I also 
have a `ulong_long' type in the GNU 3DLDF language.  The semantic
values of `ulong_long_primary', `ulong_long_secondary', etc., are
all objects of the (C++) type `unsigned long long' (if it exists, or
the largest unsigned integral type if it doesn't).  
I use `ulong_longs' where I need large integers to be represented
exactly, e.g., for routines involving prime numbers.

If you want both integer and float types, I strongly recommend having
two separate sets of rules.  I do not think it will work well to try
to determine within an action which member of the union is currently
the one you want.  I don't often use unions, but I don't recall any
straightforward way of determining this.  Even if it is possible, any
use of RTTI (run-time type information) is costly and should be
avoided if possible.  In this case, it is easily avoided.

> 
> 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! 

No, I _very strongly_ recommend not doing this!  This will fail on a
machine where floats and ints are of different sizes!  If you need
floats, it would be a much better solution to add a float member to
the union.

> 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).

Quite.  "Dirty" is the word for it.  However, you wouldn't need
pointers, since you can just cast the plain object.  In C++, you might
need `reinterpret_cast' for this, but I'm not sure.  

> 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?

You would just make it more complicated.  I suggest you not go this
route.  Something along these lines would be a better solution:

******************************

statement: declaration

statement: assignment

statement: <whatever>

...

statement: expression

expression: float_expression

expression: integer_expression

float_expression: float PLUS float

float_expression: float PLUS integer

float_expression: integer PLUS float 

integer_expression: integer PLUS integer

******************************

`expression' needn't have any semantic value at all, or it might have
a value of some other type.  For example, its semantic value  could be
an integer and be `0' if an operation succeeded and `1' if it didn't.

> > 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?

No, it's so that arithmetic is only performed on one type, either
`floats' or `doubles'.  For integer arithmetic, I've got the type
`ulong_long', as described above, with a separate set of rules.

> 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.

Well, I'll admit that writing an assembler sounds more interesting
than writing an interpreter for a C-like language, but I rather think
that there are probably other programs like this already.  If you
wrote something that hasn't been done already, and you published it
under a free license, then people might actually use it.  Much more
satisfying than having it disappear into a desk drawer.  Just my two
cents and I'm by no means trying to tell you what to do.

Just as an example, one of my plans is to write a machine-like
language for GNU 3DLDF for fast-loading macro files.  I've got lots of
ideas for it, but I've never had a chance to work on it for lack of
time.  I know that other GNU maintainers and developers have long
lists of "things to do", some of which may involve parsers.

Laurence