Re: shift/reduce (sorry)

Scott Stanchfield <scotts@metaware.com>
8 May 1997 21:26:29 -0400

          From comp.compilers

Related articles
shift/reduce (sorry) kelley@Phys.Ocean.Dal.Ca (1997-05-04)
Re: shift/reduce (sorry) scotts@metaware.com (Scott Stanchfield) (1997-05-08)
| List of all articles for this month |

From: Scott Stanchfield <scotts@metaware.com>
Newsgroups: comp.compilers
Date: 8 May 1997 21:26:29 -0400
Organization: MetaWare Incorporated
References: 97-05-049
Keywords: parse, yacc

Sounds like you have something like


functionInvocation
    : functionName exprList
    ;


exprList
    : expr
    | exprList COMMA expr
    ;


expr
    : functionInvocation
    | ... // other expr things
    ;


(which I think would give a reduce-reduce conflict, so it's not quite
the same as what you have)


If it's similar to the above, I think what you want to say is "a
function invocation inside an expr list gobbles the rest of the members
of the list." Which means that


      f a,b,c
is a call to f with expr list a,b,c and
    f a,b,g d,e,f
is a call to f with expr list a,b,g(d,e,f)


I think you need to make this assumption -- if you can't, the language
is ambiguous (unless you can add semantic checks that know how many
parameters a function expects, or add parens around args...)


If this sounds right, change your expr list to something like


exprList
    : expr
    | expr COMMA exprList
    | functionInvocation
    ;


and remove functionInvocation from expr...


I think that would work in the above case. Your milage may vary...
Hope this helps (If not, let me take a peek at the grammar...)


-- Scott




Dan Kelley wrote:
> My grammar allows subroutine invocation without putting the
> argument-list. The argument-list is a comma-separated list of
> expressions, each of type 'expr'. Subroutine invocation is considered
> to be an 'expr'.
>
> Thus
> call_some_user_function 1, 2;
> could be considered as
> (A) a function invocation with two 'expr' arguments
> or
> (B) as a comma-separated list whose first element is the value of
> the function called with single parameter '1' and whose second
> element is the expr '2'.
>
> Is there a way to insist that the parser take the 'A' choice?
--
Scott Stanchfield
MetaWare Incorporated
Santa Cruz, CA
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.