jc@mit-athena.ARPA (John Chambers) (01/25/85)
> I would particularly hate to see "deep" macro functionality added, > e.g., the ability to execute preprocessor directives inside expanded > macros. > > All who agree with me, show your support by NOT sending in your > list of neat preprocessor extensions! I'd second this, with the added comment: Every Unix(tm) I've ever seen had the m4(1) macro processor in its library. Well, OK, maybe some don't, but I betcha you could get a copy over the net if you wanted it. It's a much more powerful macro expander than C's feeble preprocessor. I've used it on a couple projects, and after you figure out how to quote things, it's relatively easy to use. It's real easy to tell make(1) how to run things through m4. Some versions of cc(1) even have an option to apply m4 automatically. How about if we restrict suggestions for new macro goodies to people who have learned to use m4? Then we could skip over the problems that have already been solved, and maybe talk about the problems that are really still with us (since m4 is itself not exactly perfect). John Chambers
guy@rlgvax.UUCP (Guy Harris) (01/28/85)
>> (Statement to the effect that the C preprocessor should not be made >> lots more feature-rich) > I'd second this, with the added comment: Every Unix(tm) I've ever seen > had the m4(1) macro processor in its library. This would be perfect, except that {x|x is a system with C} != {x|x is a UNIX or UNIX-lookalike system}. Almost all (if not all) of the systems in the difference between the first and second sets lack "m4". I still agree that an excessively feature-rich preprocessor encourages the invention of private dialects of languages; even with the current C preprocessor, things like the bastard Algol 68-like dialect that the Bourne shell and ADB are written in makes maintenance of those programs a pain at times. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
tim@cmu-cs-k.ARPA (Tim Maroney) (01/30/85)
M4 is a good macro processor, but not a great macro processor. It is powerful, but the existing implementation is not friendly to many of the powerful features. One example is recursion. Frequently you want to recurse down a list of items and apply some function to each. The list may be of variable size. This slows down M4 something fierce, although it can be done. Furthermore, long lists will cause meaningless overflow messages from the program; its buffers are of fixed size, with no provision for using extra space from the operating system if needed. The style of qutoing can be very confusing at times. I have to admit that I don't know the solution, unless it's a tool usable by an editor which helps show the matches. The input recognition, the low-level parsing of the input, ought to be more controllable. An extra LEX pass would add lots of overhead. The tokens used by M4 ought to be bindable to variable strings. Overall, though, M4 is powerful and useful. With flexible buffers and faster recursion it would be wonderful where it is only good now. -=- Tim Maroney, Carnegie-Mellon University Computation Center ARPA: Tim.Maroney@CMU-CS-K uucp: seismo!cmu-cs-k!tim CompuServe: 74176,1360 audio: shout "Hey, Tim!" "Remember all ye that existence is pure joy; that all the sorrows are but as shadows; they pass & are done; but there is that which remains." Liber AL, II:9.