Re: context dependencies

[Ron Burk]

> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden>
>> 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
>> > _______________________________________________
>> > address@hidden https://lists.gnu.org/mailman/listinfo/help-bison
>> >
>> _______________________________________________
>> address@hidden https://lists.gnu.org/mailman/listinfo/help-bison
>>
>
>