Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site cmu-cs-k.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!rochester!cmu-cs-pt!cmu-cs-k!tim
From: tim@cmu-cs-k.ARPA (Tim Maroney)
Newsgroups: net.lang.c
Subject: Re: Macro Preprocessor Extensions
Message-ID: <20980086@cmu-cs-k.ARPA>
Date: Tue, 29-Jan-85 20:42:45 EST
Article-I.D.: cmu-cs-k.20980086
Posted: Tue Jan 29 20:42:45 1985
Date-Received: Sun, 3-Feb-85 00:48:13 EST
References: <49@mit-athena.ARPA>
Organization: Carnegie-Mellon University, CS/RI
Lines: 29
Xref: seismo net.lang.c:4187

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.