[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: |
Sun, 14 Oct 2007 15:29:58 +0200 |
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
>
>
- 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, 2007/10/13
- 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 <=
- 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