help-bison
[Top][All Lists]
Advanced

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

Re: How can I fix it?


From: Hans Aberg
Subject: Re: How can I fix it?
Date: Sun, 9 Feb 2003 22:03:02 +0100

[Reply to the Bison Help list, as then more folks can help.]

At 20:25 +0100 2003/02/09, Davide Rizzo wrote:
>    I defined two similar rules which look like
>
>date_interval:  FROM    { /* exec some code -  mid-rule action */  }
>                 date    { /* exec some code - mid-rule action */  }
>                 UPTO
>                 date    { /* exec some code - normal action */  }
>        ;
>
>time_interval:   FROM    { /* exec some code - mid-rule action */  }
>                 time    { /* exec some code - mid-rule action */  }
>                 UPTO
>                 time    { /* exec some code - normal action */  }
>        ;
>
>where date and  time specifies date and time formats, such as "march 3 2004",
>"3/3/04" or  "13:45".
>I can't get the second rule to be matched, I mean, when the parser  try to
>build up the tree, I get a "parse error" right after having reduced to  the
>first "time" pattern and when the next token is UPTO. What is strange  is
>that the mid-rule actions don't work at all, while the date_interval  ones
>work fine, and that, observing the output produced by Bison, I can't see  any
>@n grouping, which should be made up of non-terminal and terminal  together
>with mid-rule action (which becomes a king of pseudo-terminal).

When you compiled, did you get a reduce/reduce error?

Midrule actions are implemented by inserting an anonymous empty variable
with action, so as you write it above, it is probably not possible to
determine in a 1-lookahead which of the two actions to use. -- Bison will
choose one of the two reductions, typically the one appearing first in the
grammar, which is the always the date.

Try to avoid midrule actions as much as possible, either by rewriting the
grammar, or by building closures in the actions which can be handled after
the whole rule has been identified.

The grammar above might be rewritten as
  time_or_date_interval:
    FROM date UPTO date    { $$ = date_interval($2, $4); }
    FROM time UPTO time    { $$ = time_interval($2, $4); }
  ;
if you really want to distingusih between days (counted in integers) and
time (counted in some other unit). -- Check Bison %union feature if you are
writing C code.

Another way to handle time is to convert all dates and times to say UTF
relative a fixed date, such as in the Julian period (starting at 1 Jan,
-4712). Then the grammar might look like:
  time_interval:
    FROM time UPTO time { $$ = $4 - $2; }
  ;

  time:
      date {...}
    | date time_of_day {...}
    | time_of_day {...}
  ;

  time_of_day:
      local_time_of_day {...}
      local_time_of_day time_zone {...}
 ;

And so on (depending on what you want).

  Hans Aberg






reply via email to

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