Re: Multitype support in bison

[Ilyes Gouta]

Hi,

Well the problem is that the generic token IDENTIFIER can refer to a
variable which can hold an integer as well as a float (depending on
its type). This is the source of my worries. How can I have a separate
set of rules for ints and floats knowing that only one set would
handle IDENTIFIER. It can't exist in the second set since it will
cause ambiguity.

Here is an example,

unary_iexpr:
    CONSTINT                                    { $<val.ival>$ = $<val.ival>1; }
    | IDENTIFIER                                  { $<val.ival>$ =
ivalue($<id>1); }
    | '(' iexpr ')'                               { $<val.ival>$ =
$<val.ival>2; }
;

iexpr:
    unary_iexpr
    | iexpr '+' unary_iexpr                             { $<val.ival>$
= $<val.ival>1 + $<val.ival>3; }
    | iexpr '-' unary_iexpr                             { $<val.ival>$
= $<val.ival>1 - $<val.ival>3; }
    | iexpr '*' unary_iexpr                             { $<val.ival>$
= $<val.ival>1 * $<val.ival>3; }
    | iexpr '/' unary_iexpr                             { $<val.ival>$
= $<val.ival>1 / $<val.ival>3; }
    | '-' unary_iexpr                                   { $<val.ival>$
= -$<val.ival>2; }
;

unary_fexpr:
    CONSTFLOAT                                    { $<val.fval>$ =
$<val.fval>1; }
    | IDENTIFIER                                  { $<val.fval>$ =
fvalue($<id>1); } // ERROR
    | '(' fexpr ')'                               { $<val.fval>$ =
$<val.fval>2; }
;

Both unary_iexpr and unary_fexpr are able to process IDENTIFIER (i.e
ambiguity). And actually, I'll have to call either ivalue($1) or
fvalue($2) depending on the nature of the said IDENTIFIER to get its
value and let bison push it in the evaluation stack.

I think, I can't have two != sets of rules. As Hans Aberg said, I'll
have to do type-checking within the actions...

Any clues?

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