🚀 go-pugleaf

In article <1284@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes:
>    #define string(s)	# s
>It is not obvious or intuitive what kind of expansion occurs.  Whereas:
>    #define string(s)	"s"
>evaluates in the way you would expect.

According to K&R, the macro argument is not substituted inside the
string literal.

>Apart from that, # operators break things.  Why weren't the Reiser
>conventions just formalised?  Oh no, that would be too easy.

Because the Reiser CPP was in violation of the closest thing to an
accepted standard for the C language prior to ANSI C.  Many
independent implementations had obeyed the rules, and there was
code that depended on that.  It would have been really hard to justify
standardizing the erroneous behavior of the Reiser cpp implementation.
(Making Boyd Roberts happy was not a primary goal of X3J11.)

>There is no basis in the language for string concatenation.  It is
>at odds with the lexical and syntactic structure of the language.

It's now part of the language.

>With operators:
>    a _op_ b
>Not:
>    a b
>for some defined operation.

C has always had unary operators.  Stringization is a unary operator.
For technical reasons it fit best in the preprocessing phase.

While an explicit catenation operator COULD have been introduced, it
would then have been a run-time operation.  The intention was for
concatenation of string literals to be a compile-time operation.

>The preprocessor and language weren't broken.  But they got `fixed' anyway.

The Reiser preprocessor was badly broken, and the C language had
no way to perform these highly desirable operations, which is why
we added support for them in the ANSI standard.