Hi John,
Your suggestion inspired me. I came up a simpler solution: instead of
eating spaces after NUMBER or ID, I did it in binary operators (such as
PLUS_SIGN '+') and special signs (such as LEFT_ROUND_BRACKET '(' ).
In Flex file only,
space [ ]
blank {space}*
...
%%
...
{blank}"+"{blank} {return PLUS;}
"("{blank} {return LEFT_ROUND_BRACKET;}
...
{space}+ {return SINGLE_SPACE_OP;}
The reason I do it this way is because expr non-terminal in my
production rule is very complicated.
It is difficult for me to trace and tag them. But the number of signs
separating them are limited and clear.
I tested a couple of cases. It can parse. I need more test to confirm this.
In any case, thanks Ron and John for your help!
Cheers,
Ricky
On Fri, Dec 2, 2016 at 2:55 AM, John P. Hartmann <jphartm...@gmail.com>
wrote:
> You will have to do that in the scanner using exclusive start states. When
> it meets blanks after a NUMBER or ID, it emits the SPACE token if the
> beginning of a number or identifier follows the blank(s):
>
> <afternumid>{
> [ \t]+/[a-z0-9] BEGIN(INITIAL); return SPACE;
> [ \t]+ BEGIN(INITIAL);
>
> }
>
> On 12/02/2016 05:19 AM, Ricky Zhang wrote:
>
>> I have read through 'handling context dependencies' section Bison manual.
>> But I still haven't figured out the proper solution to my problem.
>>
>> We have production rule:
>>
>> expr : expr SINGLE_SPACE expr { /* some operation */ }
>> | expr + expr
>> ...
>> ;
>>
>> expr: NUMBER
>> | ID
>> ;
>>
>> and also for all white space [SINGLE_SPACE | \t]* in the language should
>> be
>> ignored. Are there any easy way to solve it?
>>
>> Thanks,
>> Ricky
>> _______________________________________________
>> help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
>>
>>
_______________________________________________
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
