Re: patch to add #pushdef, #popdef to cccp,cpplib

[Craig Burley <burley at gnu dot org>]

>Yes, but that does not make it right.  Many of the extensions are poorly
>designed, poorly implemented and poorly documented.  Many of the extensions
>are not particularly useful, but because someone thought it was a good
>idea 10 years ago, we're stuck with them because a small number of people
>use them.

May I humbly add `volatile' to that list, especially after recent
discussions?  I believe I posted to USENET about the abhorrence of
such a "feature" over a year ago (probably wrt Fortran), but it was
more a theoretical argument based on my growing understanding of
the fundamentals of artificial languages (like Fortran, C, make,
and so on).

(In case anyone doesn't "get" this: `volatile' is in the class
of what I guess I'd call "widening attributes" in a linguistic
sense.  It "widens", rather than tightens, the potential meanings
of any of a target of the attribute -- a symbol name -- so, for
example, `a = b + c' suddenly means far *less* to a programmer
simply because of the presence of the feature in the language,
regardless of whether it applies specifically to any of the
variables involved.  That is, a programmer can no longer reliably
assume any of the variables or operators in such an expression
can be modified as long as computational equivalence is performed,
because extra-computational elements -- in this case, phantom
"sequence points" and required memory references -- exist, without
being explicitly specified.  An example of the opposite sort of
attribute, a "narrowing attribute", would be one that says "`b'
is not negative" -- the programmer reading the code need not be
actuely aware of the attribute to understand the code and perform
proper transformations.  In a properly designed language, all
attributes are fully narrowing, though that's challenging to achieve,
because it makes reading the code much easier.)

Perhaps we should consider researching the design for a replacement
facility that would include clear syntactic and semantic markers for
the actions people seem to desire from `volatile'.  E.g. instead of:

  volatile d, e, f;

  a = b + c;
  d = e + f + e;

Perhaps:

  __memory__ d, e, f;

  a = b + c;
  __memory_read__ (e) => ev1;
  __memory_read__ (f) => fv;
  __memory_read__ (e) => ev2;
  dv = ev1 + fv + ev2;
  dv => __memory_write__ (d);

And an automic increment might look like:

  __memory_increment__ <=> g;
  __memory_increment__ (3) <=> h;  /* increment h by 3 */

The specific names and syntax aren't important, but what is important
from a linguistic standpoint is that the syntax make it clear to the
reader that these are *not* normal function/procedure calls and
don't obey the same rules as those do.

If it's needed to specify less-constrained stuff like ordering, maybe:

  (__memory_read__ (e) => ev1,
   __memory_read__ (f) => fv);

And other somewhat portable hardware-type stuff can be covered
similarly:

  __memory_preload__ (k);

And, due to the declarations, the "normal" operations (other than
unary `&', I suppose) wouldn't be permitted on __memory__ names.
This sort of attribute would presumably have to be consistent
across argument association, etc.

Retrofitting this sort of thing into C is not an easy task (same
problem for Fortran), but it's worth thinking a bit about.

It's at least tempting to consider offering a similar design to the
above, but built around (and out of) cpp-style macros and using
system-specific asm() implementations.  That has the disadvantage
of less linguistic purity, but that's de riguer for C programmers,
but also the disadvantage of depending on a construct that seemingly
has lots of other problems.  One advantage would be that little,
if any, mucking with the C/C++/Objc front ends would be needed to
implement it, though.

Generally, though, I'm tempted to ignore problems like `volatile'
in C, since the nature of C is such that `volatile' rarely causes
real problems understanding code that doesn't use it (people
don't usually "ambush" `volatile' in their code, thankfully ;-)
and that programmers using C already know how to think through the
issues.  And compiler developers (like gcc's) can usually just
pick a favorite definition for how such a feature works and tell
users to put up with it.

        tq vm, (burley)