[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.

reply via email to

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