Re: lcc first experience

In article <fvve2b$i0q$1@[EMAIL PROTECTED]
>, jacob navia  <jacob@[EMAIL PROTECTED]
> wrote:
>Walter Roberson wrote:
>[snip]

>> I must therefore disagree with the claim that,

>>> all statements have side-
>>> effects. 

>You know perfectly well what the intent of the sentence was,

No, I do *not* understand the intent of that ****tion of the sentance
at all.

One of the semi-regular posters here takes pains to make a
distinction, of great im****tance to him, between 'functions' and
'procedures', saying (if I recall correctly) that 'functions'
return values but have no side effects, and procedures have side
effects but return no values. Personally I consider that an
incorrect and harmful distinction to make in C (since it leaves
out the possibility of having side effects -and- returning a value,
which is very common in programming, if only to signal the
success or failure of the attempted side effects). But it is
im****tant to that poster.

When Paul Heish wrote that in C "all statements have side-effects",
then I demonstrated, with reference to the C89 standard, that
the claim is untrue, at least as far as C89 defines "statements".
Paul might be defining "statements" differently; if so then he
must now indicate what he was referring to. Paul has a recognized
expertise in some aspects of C, and it would be unfortunate if some
people therefore took his claim at face value without whatever
context Paul might supply that would make claim correct in a certain
light.


>and
>you just want to show how clever you are.

Null statements and other statements without side effects are not
rare in C. Consider for example,

bignum_list factor_big_number(bignum_t num_to_factor) {
  /* to be implemented later */
}

This form of function is not some kind of special exception: the
grammar uses compound-statement at that part in function-definition and
the function body of this factor_big_number is an example of a
compound-statement in which the optional declaration and optional
statement list have both been omitted.


>Try to write a program
>consisting of only

>jumps
>labels
>empty lists
>constants


Okay, here's one:

int main(void) { return 0; }

That's the unix program 'true'. Add the appropriate include
and return EX_FAILURE and you have the unix program 'false'.

That 'return' is a jump-statement I do***ented in my previous
posting in this thread.


But in any case, my success in this challenge is irrelevant.

Paul Heish said that "all" statements in C had side effects.
I pointed out not just one but several statement forms in C
that do not have side effects. Therefore his use of "all" was
either wrong or implied an unusual meaning of "statement".
If he had said "nearly all" or "most" then there would have been
little to talk about, other than perhaps why he bothered to point out
a tautology.


Suppose I had made the following claim:

  "All of Jacob's lcc-win versions have stupid fatal errors."

Would the difference between "all" and "some" not then be of im****tance
to you? I'm sure you could easily take into stride if I had said,

  "I think lcc-win is an overall well-done product, but some
   of Jacob's lcc-win versions have stupid fatal errors."

Because if -none- of your versions -ever- have stupid fatal errors, you
are doing better than 99.99999% of the population -- it happens to
all of us from time to time, and we learn from it and go on.
But if I had said something like that, then wouldn't it have been
a *very* different meaning if I had used "all" instead of "some"?

In short, "all" vs "some" *is* an im****tant distinction, not just
a matter of "being clever".
-- 
  "MAMA: Oh--So now it's life. Money is life. Once upon a time freedom
   used to be life--now it's money. I guess the world really do change.
   WALTER: No--it was always money, Mama. We just didn't know about it."
                                              -- Lorraine Hansberry