bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH] Style change and some factoring


From: Alex Rozenman
Subject: [PATCH] Style change and some factoring
Date: Sat, 4 Jul 2009 21:50:37 +0300

Hi

I pushed the attached patch to the master. The patch contains various style
fixes (according to Akim's request) and some factoring. I will also
cherry-pick to branch-2.5.

Some points:

On Sun, Jun 28, 2009 at 2:57 PM, Akim Demaille <address@hidden> wrote:

> Too eager to play with your patch, I made several errors in my grammar.  I
> had a $from.name_get() but I forgot to declare [from].  Bison answered:
> ugrammar-pruned.y:534.37-50: reference is invalid: `$from.name_get', symbol
> not found
> IMHO it should refer to $from, not to $from.name_get.
>
I will change it. I can agree that in case of "symbol not found" error we
should show shortest possible symbol (without dots and dashes).


> Also, I had a $9foo, where 9 should have been removed.  It accepted $9 and
> left the "foo" attached to the expansion of $9.  Now that we have $[] to
> make what we mean clear, I think that it should complain about $9foo, like
> it does for the grammar symbol 9foo.  We should support $[9]foo for those
> who really mean that.
> This applies to other values of 9 and foo :)
>
I would agree with that, except it will affect backward compatibility. I
tried the same example with an old version of bison and got exactly the same
behaviour: only digit was eaten and all the rest was attached in the
generated code. Currently my code deals with positional references exactly
like the old implementations did. There is no another option, IMHO.

#define INVALID_REF (INT_MIN)
> #define LHS_REF (INT_MIN + 1)
> static long int
> parse_named_ref(char *cp, symbol_list *rule, int rule_length,
> More doc please.  What is "long int"?  Probably the domain for ind, so
> please introduce some "variant_index" typedef.
>
Please note that, actually there is two domains for indexes. When we speak
about named references, "unsigned" is very enough (I changed it). But for
positional references, there is an option for $-3 "deep" stack references.
This is the reason that "parse_ref" function must return a signed value.
"long int" is also taken from old code with intention to keep existing
functionality.

--
Best regards,
Alex Rozenman (address@hidden).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]