[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: Newbie requestion on operator precedence and how to resolve an
From: |
lfinsto1 |
Subject: |
Re: Fwd: Newbie requestion on operator precedence and how to resolve an s/r conflict correctly. |
Date: |
Wed, 20 Feb 2008 14:00:14 +0100 (CET) |
User-agent: |
SquirrelMail/1.4.9a |
"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
- Newbie requestion on operator precedence and how to resolve an s/r conflict correctly., Arlen Cuss, 2008/02/20
- Re: Newbie requestion on operator precedence and how to resolve an s/r conflict correctly., Arlen Cuss, 2008/02/20
- Re: Newbie requestion on operator precedence and how to resolve an s/r conflict correctly., lfinsto1, 2008/02/20
- Message not available
- Fwd: Newbie requestion on operator precedence and how to resolve an s/r conflict correctly., Arlen Cuss, 2008/02/20
- Re: Newbie requestion on operator precedence and how to resolve an s/r conflict correctly., Arlen Cuss, 2008/02/20
- Re: Fwd: Newbie requestion on operator precedence and how to resolve an s/r conflict correctly.,
lfinsto1 <=
- Message not available
- Newbie requestion on operator precedence and how to resolve an s/r conflict correctly., Arlen Cuss, 2008/02/20
- Re: Newbie requestion on operator precedence and how to resolve an s/r conflict correctly., lfinsto1, 2008/02/20
- Re: Newbie requestion on operator precedence and how to resolve an s/r conflict correctly., lfinsto1, 2008/02/20
Re: Newbie requestion on operator precedence and how to resolve an s/r conflict correctly., Hans Aberg, 2008/02/20