[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Re: FYI: The pleasures of the wonderful ;
From: |
Joel E. Denny |
Subject: |
Re: [PATCH] Re: FYI: The pleasures of the wonderful ; |
Date: |
Sat, 8 Nov 2008 16:22:37 -0500 (EST) |
On Sat, 8 Nov 2008, Joel E. Denny wrote:
> On Sat, 8 Nov 2008, Di-an JAN wrote:
>
> > I wrote a patch to solve this by adding the semicolon only if needed.
>
> I'm against this. I still agree with Akim's NEWS entry on branch-2.4.1,
> which says that our plan is to rid ourselves of this feature not to make
> it more robust and then be forced to maintain the extra code. I think the
> 2.3 behavior will be fine for 2.4.1 in the case of yacc.c.
... or glr.c if selected by %glr-parser. In other words, the feature is
active in the traditional case when Bison chooses both the skeleton and
language automatically. For temporary backward compatibility, this seems
fine to me.
> I'm in support
> of removing it altogether for 2.5.
>
> Of course, the feature is now deactivated for newer languages. I'd be
> surprised if anyone complained about that, but maybe the NEWS entry should
> be reworded to reflect that change.
>
> > (Am I suppose to Cc: to bison-patches?)
>
> I try to, but I frequently forget. Maybe that's because I've never seen
> the point of having both a bug-bison and a bison-patches, but I figure
> it's not worthwhile to try to change the culture.
>
> > By the way, to support languages that doesn't use semicolons, just
> > make the added semicolon a M4 macro that defaults to `;' and other
> > skeletons can define it to empty.
>
> I don't see a need to give skeletons the choice. After my recent patch,
> the feature is only active when yacc.c is selected as a default.
... or glr.c if selected by %glr-parser.
> > While writing the testcase, I noticed that Bison doesn't allow unescaped
> > newlines in string literals in user code. I think this should be up to
> > the compiler that actually interpretes the code. That's the first patch.
>
> I do not think this change should be made for 2.4.1, which is just a patch
> release. I'll let someone else figure out whether it should be in 2.5.