help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: for loops in C style


From: Laurence Finston
Subject: Re: for loops in C style
Date: Fri, 29 Feb 2008 10:48:47 +0100 (CET)

On Fri, 29 Feb 2008, Ilyes Gouta wrote:

> If I setup a new fexpr (and a new fassignment) that would accept
> nothing or expression, i.e:
> 
> fexpr:
>     | expr;
> 
> for_stmt:
>     for (fassignment; fexpr; fassignment) block
> 
> How can I define an action that would be triggered only for the empty
> expressions? (I have to differentiate between the two cases since they
> won't have a common action)

Am I missing something?  This is the simple answer to your question:

fexpr: /* Empty  */
{
  /* Action for empty case  */
};

fexpr: expr
{
  /* Action for `expr' case  */
};

> Basically what it's done is enumerating all the possibilities for the
> construction of the for loop. Is it the only way do things clearly and
> properly?

I haven't looked at the example you posted, but in my experience,
enumerating all of the possibilities for an expression or whatever is
often the best and clearest way of writing the rules.  In fact, I've
spent a certain amount of time going back and doing this after having
written the rules in a more compact and "cleverer" way first, which,
unfortunately, ended up causing problems later.  However, I wouldn't
go so far as to say that it was the only "proper" way.

My real opinion about this is that you can have simple or you can
have C-like, but not both.  

However, if I wanted something like this, my inclination would be to
write separate rules for each case, unless some cases could easily be
lumped together, store the information you need from the `assignments'
and `expr', if any, somewhere, like in a data structure within your
parameter object, write a single function for all cases and call it in
each of the rules, with appropriate arguments, based on the presence
or absence of the `assignments' and/or `expr', and, if present, their
values. 

I'm not sure about your `block'.  It may make sense from the point of
view of a formal grammar, but in practice, it means parsing the same
input multiple times.  Have you got a solution for this yet?

Laurence Finston




reply via email to

[Prev in Thread] Current Thread [Next in Thread]