bison-patches
[Top][All Lists]
Advanced

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

Re: %union foo bar baz and others { ... }


From: Akim Demaille
Subject: Re: %union foo bar baz and others { ... }
Date: Wed, 22 Jan 2003 16:55:39 +0100
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu)

 >> From: Akim Demaille <address@hidden>
 >> Date: Tue, 21 Jan 2003 13:58:23 +0100

 >> But there is some miscommunication here: I am struggling against
 >> anything between %union and {, I am *not* referring to what Bison puts
 >> between union and {.  I ask for the removal of the code that adds this
 >> feature.

 Paul> OK, here is a proposed patch to do that.

 Paul> This patch does not reverse all of the 2002-12-24 patch described in
 Paul> <http://mail.gnu.org/archive/html/bison-patches/2002-12/msg00015.html>.
 Paul> Some of the older patch fixes some POSIX conformance issues with
 Paul> YYSTYPE, and some of it removes current_braced_code which was marked
 Paul> as a "dirty hack".  This patch does not affect those changes.

Actually, the old "dirty hack" is still much better, IMHO, that the
current situation.  What I'm fighting against is precisely that
PRE_CODE etc.

 Paul> I guess that you may have expected a patch that simplifies
 Paul> scan-gram.l further, but I don't see an easy way of doing this
 Paul> without resurrecting the current_braced_code "dirty hack", and
 Paul> to some extent that resurrection would be a cure worse than the
 Paul> disease.

Where would that be?  The "dirty hack" comment was saying that, IMHO,
the "parsing" of the actions should be done elsewhere, not during the
reading of the grammar.  Actually, that's also because the parsing is
down now that we had all the problems of $n that should have been
accepted, but had been refused (problems in counting the length of a
lhs).

I'm curious: I would really like to know why you think the "dirty
hack" is dirty than the current solution.  And again, to me, the
"dirty hack" is just a path to parsing the actions elsewhere, i.e., it
is the best approximation for the time being, the code that leaves the
scanners and parsers as close as possible to what it will be in the
future.  Your code, on the contrary, to my eyes, immensely complicates
the scanner.




reply via email to

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