Re: Fwd: Newbie requestion on operator precedence and how to resolve an s/r conflict correctly.

[lfinsto1]

"Arlen Cuss" <address@hidden> wrote:

> On Feb 20, 2008 10:19 PM, <address@hidden> wrote:

> In Ruby, everything is an object, and all functions return objects (even
> if
> it's `nil'). This makes it easy for us, since we assume (or rather, we
> know)
> that all functions return objects and hence can have methods called on
> them.

I see.  It seems to me that you may need a way to distinguish
syntactically between a plain object and an object returned by a call to a
function (sorry, I won't call them "methods").  This isn't compiler
theory, just my intuition of what one needs to do when using Bison.

Do you have a formal grammar for Ruby in Backus-Naur form?  That ought to
make it easier to write your grammar.

>
>> This may be a case where you would have to extract this information in
>> an
>> action and make it available to the parser somehow, perhaps by "faking"
>> a
>> token (as I've described on this list ad nauseum).
>
> The problem isn't so much semantic as it is parsing. It's not reducing
> a(b),
> instead going ahead to shift more tokens and then reducing (b).c to a
> single
> expr.

Yes, I understood.  Sometimes information is available within the actions,
but one needs a way of making this information influence the course of the
parse.  The problem is that the rules don't "know" about what goes on in
the actions, so one needs a way of "telling them".  "Faking" a token is
one means of doing this.  In short, you somehow cause `yylex' to return
particular tokens to `yyparse' the next time or times it's called.  There
are a few complications, however.

> Declaring the grammar with precedence inherit is a great idea,

"Inherent", that is, the way the rules are written achieve the effect of
some having precedence over others, without use of special declarations. 
I have no idea of how Bison implements the latter, being a mere user of
Bison rather than a developer.

> and I can
> see
> that could help the situation, at least by making the grammar more clear.
> (sometimes reading the parser output is worrying..) I'll give you an idea
> of
> the situation:
>
> expr:           funccall { $$ = static_cast<Expr *>($1); }

Why is the cast necessary?  What's the type of `$1'?  For that matter,
what's the type of `$$', i.e., what is `YYTYPE'?

>               | IDENTIFIER      { $$ = static_cast<Expr *>($1); }
>               | FUNCTION_CALL { $$ = new FuncCallExpr(NULL, $1, NULL,
> NULL);
> }

[...]

Otherwise, it doesn't look any more cryptic to me than program code
usually does.  I suppose your `dynamic_cast' or casts are necessary?  I
don't remember the rules of when they are.  I've been meaning to look this
up.

This may or may not matter to you, but Stroustrup recommends the use of 0
over the use of NULL.  It's safer, since a malicious person might have
defined NULL in an unexpected way in a header file.  Stroustrup recommends
avoiding the use of preprocessor macros wherever possible and I find his
arguments very convincing, as I do on most other topics, too.  His views
on CPP can be found in his book _The Design and Evolution of C++_, if
you're interested.

> The semantic values construct an AST. Ruby's syntax is (much to the dismay
> of the parser) very flexible; parentheses around arguments to method calls
> are optional, which is where much of the woe here comes from. Method names
> can end in `!' or `?', which is a FUNCTION_CALL token, otherwise we assume
> any identifier could legitimately be a function call (that has to wait
> until
> runtime).

Well, someone must have written a parser for it, so it must be possible. 
I have no idea whether it's possible with Bison or not, though.

Laurence