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.
