> To make it more user friendly, the case like:
> ID SINGLE_SPACE SINGLE_SPACE ID
> should treat it as one SINGLE_SPACE without throwing syntax error.
Presumably there is some aspect of your grammar outside this fragment that
keeps you from just saying:
expr
: expr expr /* why care what kind of white space separates them?
*/
| expr '+' expr
...
;
e.g., the way Awk defines string concatenation.
On Fri, Dec 2, 2016 at 8:35 AM, Ricky Zhang <zhangchaow...@gmail.com> wrote:
> Hi Ron,
>
> I tried to simplify my production rule to present here. The non-terminal
> expr can be derived from more non-terminal besides ID and NUMBER. But I can
> safely assume that the boundary of expr is not SINGLE_SPACE.
>
> SINGLE_SPACE should not be discarded in the following cases:
> 1. Between SINGLE_QUOTE and SINGLE_QUOTE
> 2. Between DOUBLE_QUOTE and DOUBLE_QUOTE
> 3. Between expr and expr
>
> To make it more user friendly, the case like:
> ID SINGLE_SPACE SINGLE_SPACE ID
> should treat it as one SINGLE_SPACE without throwing syntax error.
>
> I have tried the suggestion in Bison document Lexical Tie-ins section. But
> it doesn't work. Here is my finding/experiment:
>
> In Flex file,
> ...
> SINGLE_SPACE [ ]
> %%
> {SINGLE_SPACE}+ { if(! should_discard_flag) return
> SINGLE_SPACE_OP; }
> ...
>
> In Bison file,
>
> expr : expr { should_discard_flag =
> false;}
> SINGLE_SPACE_OP expr { should_discard_flag = true;}
> | expr '+' expr ...
> ...
> ;
>
> The should_discard_flag flag doesn't work because the stream of the first
> expr in 'expr SINGLE_SPACE_OP expr' has not reduced to expr yet. It was
> still ID by the time Flex scan SINGLE_SPACE. The suggestion from Bison
> document Lexical Tie-ins section only works for the terminal case.
>
>
> On Fri, Dec 2, 2016 at 1:25 AM, Ron Burk <ronb...@gmail.com> wrote:
>
>> Hi Ricky,
>>
>> Just curious: What actually terminates an 'expr' production? For example,
>> if they were terminated by newlines and the parser encountered this token
>> stream:
>> ID SINGLE_SPACE '\n'
>> do you intend to treat that as a "missing right-hand-side of SINGLE_SPACE
>> operator" error?
>>
>> Likewise, I guess you're saying that this token stream:
>> ID SINGLE_SPACE SINGLE_SPACE ID
>> would generate a syntax error, penalizing the user who accidentally (or to
>> make things line up) uses two spaces instead of one?
>>
>> Trying to figure out exactly where the context boundaries are within which
>> you want white space to become significant.
>>
>> Ron
>>
>>
>>
>> On Thu, Dec 1, 2016 at 8:19 PM, Ricky Zhang <zhangchaow...@gmail.com>
>> 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
>>
>
>
_______________________________________________
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
