ANSI proposal for preprocessor strings

[Henry Spencer]

> ... your argument by analogy is weak.  Did it ever occur to
> you that implementations of Berkeley Unix exist on many computers other
> than the VAX?  (Sun, NBI, NSC, Tektronix, Pyramid, Convex, ...) The
> Reiser preprocessor undoubtedly followed most if not all of these ports
> with little alteration; the inline assembler code did not...
> ...  Register assignment conventions such as the ones Henry
> discusses have not perceptibly impeded the porting of Berkeley Unix,
> although I agree they are probably unnecessary.

This misses my point somewhat.  My contention was that the existence of
code that exploits obscure undocumented features ("obscure undocumented
features are effectively bugs", remember) is not a valid reason for
insisting that said features be cast in concrete, and that arguments to
the contrary can be applied to VAX asm() just as easily as to Reiser-
style preprocessing.  In fact, your comments strengthen my argument:
I strongly suspect that unprotected inline assembler is more common
in 4BSD than use of Reiser features.  If the former has not seriously
impeded portability to machines where it doesn't work, why should the
preservation of the latter be such a concern?

> ...  The Reiser
> preprocessor is part of a portable software environment that is used in
> many places; in fact it would not surprise me to hear that the vast
> majority of C programmers use the Reiser preprocessor, although I have
> no statistics on this.

Statistics on this wouldn't really be relevant.  The relevant question
is, how many programmers *care* whether their preprocessor has the
Reiser features or not?  I suspect that the number is modest, especially
since the Reiser features are undocumented.

> The Reiser preprocessor's string substitution behavior is clearly one
> of the most popular C extensions...

"Clearly?"  Surely it should be clear to me too, then.  It's not.
Certainly string substitution is not popular among the C programmers
I know, partly because it is shunned as an unportable accident of a
particular implementation.

> and for that reason alone deserves
> careful consideration.  I find it more than a little odd that it is
> given such short shrift by some participants in this discussion when
> rather more radical proposals such as case ranges are being casually
> bandied about.

First, how do you know it wasn't given careful consideration?  My
impression is that the discussion about the Reiser features consumed
a significant fraction of the language subcommittee's time for months.
Second, there is a lot of casual bandying-about of silly features
whenever a language is being standardized; one of the crosses that
standards committees have to bear is that they have to shoot down
all the whacko ideas that crawl out of the woodwork.  Case ranges
are by no means the worst of it.  And by the way, case ranges have not
survived the latest revision of the C draft (11 Feb 1985).

> My own feeling is that the ANSI C standard is not the place to make C
> perfect; C (including its common extensions) has enough imperfections
> that it seems pointless to break existing code just to fix a tiny
> fraction of them.  I suggest that people concentrate their corrective
> impulses on a new language, such as C++.

This is actually a fairly good statement of one of the committee's goals.
The question is not whether the Reiser features are imperfect, but
whether they are part of C at all.  They occur in only a few of the
numerous C implementations, although admittedly one of those is very
influential and has been widely ported.  They do not appear in K&R,
the closest thing we had to a written standard before.  (In fact, a
strict reading of K&R makes the Reiser features illegal.)  Are they part
of the language, or just an aberrant feature of one implementation
that was copied by one or two others?  This is most definitely the
sort of question that is the business of a standards committee.  I'm
sure that at least half of the committee members wish, by now, that
it wasn't.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry