kpmartin@watmath.UUCP (Kevin Martin) (10/05/84)
>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
henry@utzoo.UUCP (Henry Spencer) (10/07/84)
> What more justification do you need than a good use for it?
Basically, it should be useful enough, to enough people, to justify
forcing all C implementors to provide it. It also shouldn't break
things, and it should be clean and simple enough that its prospective
customers can understand it. Finally, it should be sufficiently well
understood (this normally implies substantial experience with one or
more experimental implementations) that its consequences and side
effects are known. Implementing something just because it looks useful
is the way you get kitchen-sink systems like PL/I and OS/360.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry