Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site watmath.UUCP
Path: utzoo!watmath!kpmartin
From: kpmartin@watmath.UUCP (Kevin Martin)
Newsgroups: net.lang.c
Subject: How idiot-proof must CPP be?
Message-ID: <9297@watmath.UUCP>
Date: Fri, 5-Oct-84 14:20:01 EDT
Article-I.D.: watmath.9297
Posted: Fri Oct  5 14:20:01 1984
Date-Received: Sat, 6-Oct-84 05:22:36 EDT
References: <9225@watmath.UUCP> <522@wjh12.UUCP>
Reply-To: kpmartin@watmath.UUCP (Kevin Martin)
Organization: U of Waterloo, Ontario
Lines: 36

>Kevin Martin proposes extensions to the CPP, making it a fundamentally
>more powerful macro processor in several ways.  I will not examine
>his proposals in detail, but any consideration of them should include
>a lot of thought about the really dangerous and impossible-to-read
>things that could be done with them.  Martin conveniently provides an
>example:
>> The combination of the first three features allows generation of ragged
>> initialized arrays: Each row is given a name using #eval and token
>> concatanation, the row is given storage class 'static', and, by switching
>> to another diversion, the row pointer in the edge vector can be
>> initialized to point to the row.
>Heaven help us!
Right now, I have an approx. 100-row ragged array manually coded with
funny names (like row_23) that I would rather never have to see, nor type.
Having the above capability would make this so much easier to use.

>One should think very carefully before extending the CPP, because macro
>semantics are extremely dangerous.  And they are dangerous in a
>different way than pointers.  Complex usage of a powerful macro
>processor such as MACRO-11 or m4 is not just hard to make readable; it
>is impossible to make readable.  I consider the CPP's lack of power a
>feature.
I agree that many uses of macros are stupid or obscure, but then, they
also often improve the readability (compare getchar with its expansion!)
of the program (as in the ragged-array example).

>Ill-considered wish-lists can be fun; still, I would like to see
>proposed features considered guilty until proven innocent, meaning that
>people who propose them should make some attempt to justify them beyond
>saying "Wow, look what we could do with this!"
>	Sam Kendall	  {allegra,ihnp4,ima,amd}!wjh12!kendall
>	Delft Consulting Corp.	    decvax!genrad!wjh12!kendall
What more justification do you need than a good use for it? I would
give you the actual code that 'uses' it, but it isn't worth my time to
re-code to take advantage of a non-existant feature
                          Kevin Martin, UofW Software Development Group