Draft standard questions

[chris at umcp-cs.UUCP]

>In article <2364 at umcp-cs.UUCP> I wrote:
>>...  The draft standard says that because `sin' appears here
>>without a following `(', it is not macro-expanded; thus this in
>>fact passes the address of the library function.

In article <1054 at ttrdc.UUCP> levy at ttrdc.UUCP (Daniel R. Levy) replies:
>If so, this is a "new" feature at least compared with AT&T SysV (could
>someone check out BSD and others?) C compilers, which give an error message
>about "argument mismatch" if something like this is tried.

As far as I know, the current preprocessor description in the
standard is unlike any and all available preprocessors.  According
to Jim Williams there is still some argument over just what is to
be `correct' behaviour.  (It is handy, this knowing someone who
actually goes to these meetings.  I hope I have not too badly
mis-paraphrased Jim.)  This is substantiated by the minutes sent
out to `alternate members'; there were, it seems, some four different
formal descriptions proposed.  If there is enough interest I will
borrow Fred's minutes again and post an extract.  (I am not even
an alternate member: `interested bystander' is rather more accurate.)

>I thought standards were supposed to, er, be codifications of a
>combination of the best features in existing compilers, not invent
>things out of the blue sky...

There are some rather major variances between existing C compilers,
and in each such case the committee must either pick one, or invent
something new.  Most of the `inventive stuff' in the part traditionally
done by /lib/ccom comes from C++, with which, at least, people have
had experience.  I have reservations about how well some of the
other `inventions' will work.

By the bye, that reminds me: Jim was going to mention this, but I
have not seen it, so I will do it.  The current draft standard
contains two new preprocessor operators, the `stringiser' `#' and
the token-concatenater `##'.  For example,

	#define glorp(a, b) glump("a " #a " string", _##b)
	glorp(strange, thing)

turns into

	glump("a strange string", _thing)

In one of the meetings someone proposed using `#"' and `#&', as
they are at least slightly more suggestive as to what is occurring:

	#define	glorp(a, b) glump("a " #"a " string", _#&b)

This was quickly followed by another proposal:

	#define	glorp(a, b) glump("a " __STR(a) " string", __CAT(_, b))

Naturally, this latter proposal caused much stir, and most likely
due to lack of time for consideration, both were rejected.

I think the current `#' and `##' are rather unfortunate forms, not
suggestive of anything, and leaving little room for future expansion.
`#"' and `#&' seem better---although I am uncertain of the first,
for it makes discovering what is quoted in unpreprocessed text more
difficult: a little more for programs, and, I think, much more for
programmers.  The final form is better still, but seems to have
rather more impact on the rest of the language (by which I mean I
am not ready to decide about it without first trying it).

Now then, if there is great outcry *and* agreement on the part of
the `C community' (as represented by net.lang.c), we may be able
to change this.  I would like to propose a modification of the
third form above:

	#define	glorp(a, b) glump("a " #str(a) " string", #cat(_, b))

This is somewhat readable (unlike `#' and `##', and `#"'), and
more importantly, expandable: if `#str' and `#cat' turn out to
be bad or insufficient, there are alternatives.  `#' and `##'
leaves `###', `####', `#####' ... or perhaps `###func(args)':
hardly aesthetic.

On the other hand, we could try to come up with a formal definition
of Resier-cpp semantics. . . .
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu