Re: help please?

Kenny MacDermid <[email protected]> Sat, 1 May 2004 17:49:14 -0300
Newsgroups gmane.comp.lang.prothon.devel
Message-ID <[email protected]>
On Fri, Apr 30, 2004 at 12:40:40PM -0700, Mark Hahn wrote:
> I'm trying to add some features to the parser, and I'm
> having problems just as I've always had.  I thought maybe
> you could answer a question or two.
> 
> I want to be able to distinguish between these two cases:
>     x = obj$func
> and
>     x = obj$func()
> Here is how I am trying to do it (note last two lines):
> 
> obj:
>         '$'
>     |   target_param
>     |   INT_
>     |   LONG_
>     |   FLOAT_
>     |   INT_IMAG
>     |   FLOAT_IMAG
>     |   STRING
>     |   '{' brace_params '}'
>     |   '[' list_params ']'
>     |   '(' expr ')'
>     |   '(' tuple_params ')'
>     |   obj '(' function_params ')'
>     |   attr_ref '(' function_params ')'
>     |   unbound_ref '(' function_params ')'
>     |   obj '$' LABEL '(' function_params ')'
>     |   obj '$' LABEL
>     ;
> 
> The problem is that the last case is always selected.  So
> obj$func() is parsed as
>     obj -> obj '$' LABEL
>     obj -> obj '(' function_params ')'
> When this happens I try rearraning line order, adding %prec
> commands, but nothing works.  It is as if the parser does
> not like to "look ahead".  I must admit that I have not
> taken the trouble to understand BISON and what it does or
> what type of grammer it parses.  So excuse my ignorance (or
> don't).
> 

I really have no idea right at the moment. Bison is suppose to
choose to shift the '(' instead of reduce in the event of a
conflict, but doesn't seem to be doing that. Also looking at
the state machine you can see it reduce, and completely ignore
the '(':

-----
state 296

  172 obj: obj '$' LABEL . '(' function_params ')'
  173    | obj '$' LABEL .  ['(', <others removed>]

    $default  reduce using rule 173 (obj)
-----

Odd. I cannot ever reproduce it in a simple language I created
to test if it had something to do w/ the left recursion. This
language (with the same label structure) parses fine:

-----
goal: '$'
    | 'a'
    | '(' 'e' ')'
    | '(' goal ')'
    | '.' 'l'
    | '^' 'l'
    | '&' 'l'
    | '@' 'l'
    | 'l'
    | goal '.' 'l'
    | goal '[' 's' ']'
    | goal '(' 'f' ')'
    | goal '$' 'l' '(' 'f' ')'
    | goal '$' 'l'
;
-----

This one shifts the '(', but complains about shift/reduce
problems (as it should).

Hrm.... I don't as of yet have a box that prothon will compile
on (my openbsd doesn't have apr, and my solaris has problems
with the newest bison, that I can't change some system files
to fix), but send me the TRACE_PARSER output from a simple
example with your parser.output (use bison -v), and I can take
a look. Although it probably won't show anything other the
what we already know, it reduces after the LABEL.

The only other thing I can think of is that the conflicts are
throwing it for a loop. Obj has a lot of repeated matches like:

obj -> target_param -> attr_ref -> obj '.' LABEL
obj -> obj '.' LABEL

I'll look into it more later and run it through any graphing
tools and see if I can figure it out.

Good luck,

Kenny