call to revolt

[J. Horsmeier]

In article <BURLEY.91Jun27120009 at pogo.gnu.ai.mit.edu> burley at pogo.gnu.ai.mit.edu (Craig Burley) writes:
>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 claim ANSI C is wrong, I was simply replying to a 'call to revolt',
'cause (I repeat myself), I like the philosophy: `You get what you deserve',
and given the hypothetical assumption that ANSI C was `going to forbid lvalue
casts' (read the original posting), I responded, that's all :-)

>   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.
>

Why should any committee forbid, non-portable, non-clearly-defined tricks etc.
offered by any language. Ripping these things out of a language is not doing
any good to that language. I *do* like the idea of commitment to a standard as
long as this standard simply enumerates all these non-portability pitfalls and
still allows one to use these hacks. Sometimes these things come in handy on
particular hardware environments, as long as you *know* and *realize* that
you're hacking close to the edge.

>   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
[...]

No, as long as we are using the same tool (language), we can understand each
other. If both parties conform to the rules of the tool, they can communicate
the way they want. Even when a sentence contains syntactic or semantic errors,
people are capable of understanding each other. (This sentence contains two
errors).

>
>    ((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".
[...]

Yep, that's exactly what I want (only with the stuff I'm currently working on).
I want an integer value plugged into the memory locations, previously containing
a pointer value. I know what I'm doing, I know it's not portable, I know about
different pointer sizes, I know it's not ethical,  etc. etc. etc. :-)
I know it can be done `the neat way', but all I want is a quick hack to do
the job, and I love it if a language gives me the opportunity to do so.
The stuff I'm working on now is not supposed to be portable, it's a dead end
anyhow, they just want the beast up and running for about six more months,
afterwards they let it die peacefully, so why bother about standards? 

>
>So please stop complaining about ANSI C as if it is restricting something
[...]

I'm not complaining about ANSI C. I like it when committees try to make
things explicit and `clear'. It can be a great help. Hidden language `features'
are a mess: define and elucidate them, but don't forbid them (which was the
original assumption). Label them as dangerous, bad practice or whatever and
clarify to the zomby woofs who still want to use them, that they're naughty boys
and girls =8^)

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

Who wants trigraphs anyway?

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

And please, let's not make a thread out of this, it's not worth the trouble.

See ya,

Jos


+----------------------------------------------------------------------+
|O   J.A. Horsmeier AND Software B.V.        phone : +31 10 4367100   O|
|O                  Westersingel 106/108     fax   : +31 10 4367110   O|
|O                  3015 LD  Rotterdam NL    e-mail: jos at and.nl       O|
|O--------------------------------------------------------------------O|
|O               I am a Hamburger (F. Zappa 1974)                     O|
+----------------------------------------------------------------------+