Re: Multitype support in bison

[Ilyes Gouta]

Thank you, Laurence, for your answer!
I'm going to experiment a bit with all this and I'll keep you posted.

BR,
Ilyes Gouta.

On 10/14/07, Laurence Finston <address@hidden> wrote:
> 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
>
>