"Arlen Cuss" <[EMAIL PROTECTED]> wrote: > On Feb 20, 2008 10:19 PM, <[EMAIL PROTECTED]> 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 _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison