Re: Statement on Schildt submitted to wikipedia today

On Sep 11, 11:11 pm, Seebs <usenet-nos...@xxxxxxxxx> wrote:
On 2009-09-11,spinoza1111<spinoza1...@xxxxxxxxx> wrote:

I'm busy at this time, but this is an incredibly unethical thing for
you to say, because it is ex cathedra and a misuse of your technical
authority.

Fascinating assertion.

The functionality IS the stack, and I really, really hope you know
this.

Well, now I know how you are using the word.

However, what Schildt described was not an abstract stack, but a specific
layout in which the stack and heap were separate and non-overlapping regions
of memory, such that no address of any "heap" object is between any two
"stack" objects, and vice versa.

This is of course a respected way of presenting the key facts of
runtime, as opposed to obscuring them. No competent student will rely
upon contiguity, nor does Schildt imply contiguity.

The runtime behavior of a normal C program must be explained by
using the stack as an abstraction, because as soon as one procedure
can have > 1 activations, it needs > 1 activation records holding its
parameters, its local variables, and the return address. There is no
way to store and retrieve these activation records which does not
involve stack "like" mechanisms: the stack is provably the minimal
amount of mechanism needed.

Absolutely correct!

... But "minimal amount of mechanism" is not the same as "how it really
works".

Herb, as I have said, was NOT writing for Morgan Kauffman and fourth
year compsci majors.

As soon as you write

For 1 (or 2), N factorial is 1 (or 2): for n, n factorial is n*(the
factorial of n-1)

you have a function which can only be calculated by something that
uses a stack. If it uses an array, all it needs to do is access the
beginning or end of the array, aka the top of the stack.

This is a fascinating assertion, but not true -- many compilers will
implement this function without recursion.

Certain functions can be expressed iteratively, and factorial is one
example. Others cannot. But to convert a recursive factorial into the
iterative equivalent would take a lot of compile time optimization.

What I hope you mean is that most programmers will write N factorial
using iteration.

Wikipedia contains the claim that any recursive function can be
iteratively expressed. I do not think this is true, for example, in
the case of recursive descent parsing. If memory serves, my old
MacDonald-Elsevier "Monograph in Computer Science" on "Recursive
Programming" contained the contrary claim that not all functions that
can be calculated recursively can be calculated iteratively, and gave
as an example, if memory serves, Ackermann's function.

But too my knowledge there is no computer that computes all recursive
functions iteratively UNLESS it does so using a stack: the stack then
makes the calculation not iterative, so there you are.


Therefore, once recursive call exists, the stack exists. An
"intuitionist" mathematician knows this: a "Platonist" realizes it a
few minutes later.

No.

Again, "the stack" is not an abstract concept,

Aux d'autres, ma vielle. It IS an abstract concept. Did you flunk baby
computer science?

but a specific region of
storage allocated in a particular way.  If Schildt had said "a useful way
to think about automatic variable allocation is...", I probably wouldn't
be complaining; it *is* a useful way to think about automatic variable
allocation.

But what he claimed was that there existed a memory layout, and that all
automatic variables were allocated in a specific region of memory, and that
all heap variables were allocated in another, and this is not true,
and believing it is misleading.

He made no such claim.

Peter, I regard you as "elite" wrt computer science: but from this
comment you make alone, I see you are like the ruling class which is
willing to destroy American industry to preserve the profits of a
view, because you are willing to destroy knowledge and memory merely
to be right, and preserve a standard designed primarily to protect
profits.

I regard you as schizophrenic.

Soviet psychiatry.
 
There is simply no evidence or data to
support the contention that the standard was designed "to protect profits".

On the contrary, young fellow, many of us noticed in 1980 that
suddenly, the public interest had no traction whatsoever in computer
science. You grew up (half way) in the selfish world created by
Thatcher and Reagan, but I saw my first homeless mother and child on
First Avenue in Seattle in 1986, when I was 36. I suggest you grow up
more.


Indeed, as pointed out with concrete examples, the standard was designed
in a way which is extremely unlikely to achieve your described theory of
how companies were trying to protect profits.

How strange. "Sequence points" were designed to protect profits,
because you lacked the courage to insist on left to right
optimization, to protect the investment of developers who'd unwisely
over-optimized a language which is, owing to aliasing alone, unsafe at
any speed, and unsafe for optimization...as your example demonstrates.
Within OS and compiler development shops, C is surrounded by tools
which make it somewhat safe but in general it shouldn't be optimized,
especially for applications and most especially for life and mission
critical systems.



I'd also warn you that I'd never heard of your famous "sequence
points" prior to the standards push of the 1990s, and I am confirming
a little theory that I have: that you invented this claptrap to make
optimizing, but incorrect, compilers, correct.

Again, I wasn't involved in any of this, but I don't think I buy that
argument at all.  The goal of the as-if rule and sequence point rules
is to make it possible for developers to distinguish between operations
for which they require a particular sequencing, and operations for which
they do not.

"Sequence points" ignored the fact that a sensible sequence is implied
by K & R. Although few competent programmers would code i=i++, it's
clear from early C what's meant. i gets the old value of i (because
that's the value of the right side of the assignment) but is then
overwritten by i plus one. Let's try this out (using Microsoft .Net C+
+ but in C mode with file type .C):

#include <stdio.H>

int main()
{
int intIndex1;
intIndex1 = 5;
intIndex1 = intIndex1++; /* Whee */
printf("%d\n", intIndex1++);
printf("%d\n", intIndex1 = intIndex1++);
printf("%d\n", intIndex1);
}

A K&R understanding of this gives 6 7 8 and that is what I get. It's
not "undefined". Why make it so?

I agree that there are some puzzles here. What is the value of "the
right hand side" of i=j++?

But I think the puzzle is cleared up once you posit, as did Herb, a
paper machine with an ideal stack. This prints 6:

#include <stdio.H>

int main()
{
int intIndex1;
int intIndex2;
intIndex1 = 5;
intIndex2 = 6;
printf("%d\n", intIndex1 = intIndex2++);
}

because intIndex2 when it is 6 is pushed on the stack but incremented
in its addressible location.

Truly pathological constructs such as i=(j)++ have no meaning and
should have resulted in compile-time diagnostics, because a close
reading of either edition of K&R, which should have controlled, makes
it obvious that pre and post increment need lValues to be meaningful.

Requiring "standard" C programs to avoid using post and pre increment
on LValues would have been a tough and painful decision that would
have caused software vendors (and not only compiler vendors) to call
your boss. But the operation has no meaning given a close reading of K
& R, despite the fact that they allow it.

But, apparently to preserve broken compilers and their optimizers, you
seem to have invented this broken notion of a "sequence point". And I
conclude this was done because of commercial pressure.


K & R designed C at a
time when it was not known how important it was to specify the
sequence of arithmetic and logical operators, but common C compilers
prior to your broken standard evaluated left to right with no
nonsense, and did not try to over-optimize such a profoundly unsafe
language.

Before the standard, different compilers evaluated in different orders under
different circumstances.  After the standard, it's the same.

No, you make order of evaluation "undefined". You make results
"undefined".

More on your other points when I have more time.

It would be more interesting if you'd stop dragging in your conspiracy
theory crap and actually talk about the language.

I retain the right to speak truth to power.

-s
--
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nos...@xxxxxxxxxxxxx://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
--
comp.lang.c.moderated - moderation address: c...@xxxxxxxxxxxx -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line.  Sorry.
--
comp.lang.c.moderated - moderation address: clcm@xxxxxxxxxxxx -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
.

Relevant Pages

  • Re: Why C is really a bad programming language
    ... questions answer depended on the absence of a sequence point, ... make existing C compilers from powerful manufacturers "compliant". ... understood to constitute C, not the standard. ... judging from their document on Schildt, aren't competent programmers ...
    (comp.lang.c)
  • Re: More fun with Misers CASE
    ... So language compilers are often 1 megabyte ... We want standard Forth to be something that can be ... the return stack than the interpreter. ... control structures yet that look good enough to port, ...
    (comp.lang.forth)
  • Re: TAIL (optimised tail call)
    ... break their non-ans-compliant code that manipulates the return stack. ... What's needed is a standard way to turn off tail call optimization ... Some compilers hold the return address in a register for functions ...
    (comp.lang.forth)
  • Re: Why We Use C Than C++...
    ... The reason C compilers don't adopt it is for binary ... >>compatibility with C compilers that predate function prototypes. ... >>difference (callee cleans the stack, rather than the caller) can amount to ... either standard mandates a word about performance, ...
    (comp.lang.c)
  • Re: why this program is not crashing
    ... > used some really wierd C compilers, ... A pointer to void shall have the same representation and alignment ... The standard specifically does not specify this and make it mandatory. ... > compiler would need to stack it before the call to printf. ...
    (comp.lang.c)