call to revolt

[Craig Burley]

In article <998 at baby.and.nl> jos at and.nl (J. Horsmeier) writes:

   It's my own choice.

Create your own language to make your own choices.  But don't try and claim
ANSI C is "wrong" or failed simply because you can't express something that
is meaningless or has a variety of meanings to different people.  C already
had enough baggage like that before ANSI got ahold of it.  No reason to add
anything new.

   I don't want any committee to forbid things like that 
   in any language.

Then don't use any languages standardized by any committees.  Like I said,
create your own language.  I've done it when it was appropriate to the task
at hand.

   A language is supposed to be a tool to express yourself, 
   the way you want and like to do so :-)

Wrong.  Take a bunch of cans of paint, reach your hands into arbitrary cans,
splatter paint on a canvas or wall, and you have just expressed yourself the
way you want -- but nobody is likely to understand what you are trying to
express.  Use a language of expression, whether abstract, symbolic, formal,
whatever, and do it well, and others will be able to understand it.  That is
the purpose of language.  If you want to do whatever you feel like as far
as "expressing yourself" in a computer language, like I said, write your own,
or at least use assembler (or, better yet, machine code the stuff directly).
But if you want others to be able to understand what you are writing, then
use the language, and learn to use it properly.

   Restricting syntactic and/or semantic
   richness of a language, just to avoid potential abuse by some zomby woofs
   from outer space is bad practice IMHO :-)

I agree, but that's not the case with disallowing

    ((int) thing)++;

and suchlike.  The ONLY "proper" interpretation of the above construct, given
what casts are in C, would be the following:

    Get the value of "thing".
    Convert that value (a temporary in a register, basically) to type "int".
    Increment that temporary.

But you seem to want it to mean something different, like:

    Get the value of "thing".
    Convert that value to type "int".
    Increment the result.
    Convert the result back to the type of "thing".
    Write the result back to "thing".

Or:

    Pretend "thing" really is an integer, and increment that.

These two things can have different results, and certainly they have results
different from the first definition, which does nothing.

Because lots of compilers allow this without warning (failings in those
compilers, perhaps), you can get away with the construct and write nonportable
and even incorrect code.  You might even discover that a compiler did something
unexpected with your code.  But these compilers can interpret your construct
however they wish, and only if they specifically describe what they do in their
documentation can you legitimately complain about their implementation (if it
is different from their description).

So please stop complaining about ANSI C as if it is restricting something
that should work the way you want, because:

1.  ANSI C did not restrict it, the restriction was always there in the
    language even if not in all compilers that implemented the language, as
    many others have mentioned.

2.  The whole point of ANSI C was to create a standard language based on a
    variety of dialects called "C" that somehow managed to satisfy a variety
    of criteria, primarily the portability of conforming programs to a wide
    variety of architectures and the ease of conversion from the various
    old dialects to the new standard language.  I believe it is reasonable to
    state that none of the individual criteria were satisfied 100%, but that
    the degree of satisfaction is higher for the criteria they deemed more
    important (at least for the most part).  It certainly is true that no
    language definition could have satisfied all the criteria 100%.

3.  The construct you show can be interpreted in a variety of ways by various
    experienced C programmers, as I illustrated above, and one of those
    interpretations is thoroughly nonportable, another is entirely out of the
    mold of C (the idea of storing a compiler-generated temporary back into
    its source location, without explicitly specifying an lvalue for the
    destination, does not exist in C, to my knowledge), and the other (the one
    I claim is most natural) is completely useless.

4.  There are better (more portable, more readable) ways to do what you want.
    (By "more readable" I do NOT mean "expressed in fewer characters", but
    "expressed within a subset of the language understood by a greater number
    of people compared to using a specific but rarely used construct".  For
    example, the phrase "Avoid making things more obscure than necessary" is
    more readable, despite being longer, than "Eschew obfuscation", even though
    the latter is funnier (once you look up the words) and, to the minority
    with a large enough vocabulary, more to the point.)

ANSI C has some dumb things about it (trigraphs spring immediately to mind...
OUCH! :-), but disallowing this construct is NOT one of them.
--

James Craig Burley, Software Craftsperson    burley at gnu.ai.mit.edu