Joel E. Denny wrote: > On Tue, 7 Oct 2008, Joel E. Denny wrote: > >> Di-an's email has prompted me to change the way Bison computes output file >> names. I'd appreciate any opinions from other developers as well on this >> issue. I feel we need to settle it before the 2.4 release so we don't >> find ourselves stuck with more backward compatibility problems. > > I didn't realize how difficult this would be until I got into it. This is > a significant change that could affect many people, so it really needs one > more pair of eyes at the very least. > > We should encourage people to use %language, which, > after this patch, will activate a simplified and more general set of > naming rules.
It seems okay (I only skimmed output.c, concentrating on the m4 and texinfo parts), and definitely an improvement. Thanks very much. However, the part on "how to write a new language" seems uselessly detailed, and that's a symptom of two problems. First, you wrote it as a developer and not as a user, but you tried anyway to think as a user. This caused some quirks; for example, you can assume that anyone writing a skeleton for a new language is comfortable enough working in the Bison build tree, and would start patching getargs.c to add his language (I did so -- actually I *implemented* %language :-) at the beginning of my Java skeleton project, even before starting the m4 parts) and by writing the *-skel.m4 back-end file. Second, you are not considering the common use case, and are hoping that people *will* transition to %language. My experience with developer tools (Autoconf and Bison especially) tells me that this is harder than you think. Most people are using either -o or ylwrap (which uses -y and implement sane naming on top of that), and those people already have sane names. They won't understand why they should require a brand-new Bison. I'll try to make a suggestion: besides -y, which is anyway a compatibility mode, we can assume that most users are probably using *a -o option that does not specify a filename ending in .tab or _tab, and have the grammar in a .y file*. The only difference with the new rules, then, is in how the defines file is named (with a fixed .h/.hh extension, or instead by changing c's to h's in the -o file). * Is this true? If not, can we make this true at least for C and C++ by changing the new conventions? * Does it make sense to change the new convention so that the "change c to h" part holds also in that case? * Can we then rewrite the documentation saying that -o, with a filename not ending in .tab or _tab, follows the new conventions? * Maybe can we make this true in the implementation, rather than just write the documentation to match? Even if it adds a few lines of code, I believe it's worthwhile because it means that 99% of the executions would actually follow the new execution path (and the old one would be tested by -y and by the testsuite). > I think it would be cleaner if we could change %skeleton to activate the > new naming rules as well. However, I worry this might break makefiles for > users who have already been using %skeleton "lalr1.cc", so I didn't do > that. But I'm open to it if others think this isn't an issue. I wouldn't worry much about %skeleton, a quick Google Code Search says there's no change there. So, for this I would say go ahead. And in fact, I think we can change the Texinfo documentation assuming that no one ever used it except people anyway involved in the development of Bison (and mention changes in NEWS only). It would be a separate patch, but one that would also simplify some things. In other words: I think this is worthwhile, and ought to be done definitely before the first stable release that supports %language comes out. However, it needs some more thought. Paolo
