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

[Arlen Cuss]

I did it again. I should check my mail preferences for replying.
--

Hey,

On Feb 21, 2008 12:00 AM, <address@hidden> wrote:

> 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.

I'm not really fussed if we call them methods or functions, so no worries
there. :) I'm not sure if it's so important that we need to distinguish the
two things (talking also on the topic of Bison only), but perhaps it would
help.

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

As far as I know, one doesn't exist. :(! The reference of the language tends
to be just the main implementation.

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.

As my previous/completion message to the list explains, I did just that. :)
I've had to use the technique in some other situations where the grammar of
the language is particularly nasty (blocks. they are interesting creatures).

"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.

I haven't a clue either, to be frank, but it seems to work.


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

YYTYPE is a massive union. funccall is declared %type <funccall>, so it uses
that element in the union. The union's funccall member is a FuncCallExpr*,
and that class derives from Expr. You're 100% right, the cast is
unnecessary. Thanks. :)


> 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.

Thanks for the suggestion! I think I really ought to read some of his books.
I read his FAQ online at some point which mentioned the NULL/0 issue, but
I'm not so fazed by it, myself. I prefer (visually) NULL, and it seems to be
more `semantically' accurate. If I was wearing a tinfoil hat, then I might
define it as 0 myself. I also agree with avoiding preprocessor macros, and
gotos -- but I still use both, when appropriate.

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.

I hope it is. :) I'll keep on trekking.


> Laurence
>


Cheers!
Arlen