http://catless.ncl.ac.uk/Risks/26.06.html#subj12

This shall shortly also be on the Digest, to where people may respond
to it. However, responses are competently moderated.

The risk: Once you write a crap book, there is the risk that it won't
be forgotten even ten years later, because some people won't leave it
alone. Poor Schildt.
According to this "spinoza" guy there are no bad books, but some just
destroy your reputation forever.

On May 9, 5:43=A0am, "christian.bau" <christian....@cbau.wanadoo.co.uk>
wrote:
>
> The risk: Once you write a crap book, there is the risk that it won't
> be forgotten even ten years later, because some people won't leave it
> alone. Poor Schildt.
> According to this "spinoza" guy there are no bad books, but some just
> destroy your reputation forever.

Hmmmm, not entirely sure about that...after I downloaded
Microsoft Visual C++ Express I was forced to try to figure
out how it worked by reading the documentation about
Visual Studio on MSDN (it uses the modern documentation
strategy: no help, mostly ESP, and web pages).

Every lesson in the tutorials, HUNDREDS of them,
encouraged you to read HERB SCHILDT's book on C++
if you weren't familiar with the language...how
good is THAT book?

---
William Ernest Reid

On 2010-05-09, Bill Reid <hormelfree@gmail.com> wrote:
> Every lesson in the tutorials, HUNDREDS of them,
> encouraged you to read HERB SCHILDT's book on C++
> if you weren't familiar with the language...how
> good is THAT book?

I've seen nothing to suggest that it's noticably better.  MSDN, though,
is full of nonsense.  They have a page claiming that parentheses allow
you to control order of evaluation.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On May 10, 6:40=A0am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-05-09, Bill Reid <hormelf...@gmail.com> wrote:
>
> > Every lesson in the tutorials, HUNDREDS of them,
> > encouraged you to read HERB SCHILDT's book on C++
> > if you weren't familiar with the language...how
> > good is THAT book?
>
> I've seen nothing to suggest that it's noticably better. =A0MSDN, though,
> is full of nonsense. =A0They have a page claiming that parentheses allow
> you to control order of evaluation.

Which they do IN PRACTICE. Your vandalism ("sequence points") on
behalf of vendors can be safely ignored simply by not allowing
students to use preincrement and postincrement, which were poorly
thought out by Ritchie at a time when the distinction between value
and lValue was not clear.

You have a Fascistic hatred of knowledge and seek to replace it by
unprovable if unrefutable negative claims accompanied by an
adolescent's superior smirk, and your white skin privilege.

All generalizations outside of pure mathematics (which does not embed
computer science, computer science being a social praxis) have
exceptions. It is far, far more important that students learn that
order of evaluation is changed by parentheses than it is to learn the
mess you and your other misfit friends made of C.
>
> -s
> --
> Copyright 2010, all wrongs reversed. =A0Peter Seebach / usenet-nos...@see=
bs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny picturesht=
tp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On May 9, 8:43=A0pm, "christian.bau" <christian....@cbau.wanadoo.co.uk>
wrote:
> The risk: Once you write a crap book, there is the risk that it won't
> be forgotten even ten years later, because some people won't leave it
> alone. Poor Schildt.

"Crap book" is Nazi language. To a civilized person, there is no such
thing. Since truth is always partial outside of pure mathematics, even
a highly flawed book can be useful.

> According to this "spinoza" guy there are no bad books, but some just
> destroy your reputation forever.

....only with sniggering little assholes trying to show how superior
they are because they use Linux, even though they can't code worth
dick.

On May 9, 3:40=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-05-09, Bill Reid <hormelf...@gmail.com> wrote:
>
> > Every lesson in the tutorials, HUNDREDS of them,
> > encouraged you to read HERB SCHILDT's book on C++
> > if you weren't familiar with the language...how
> > good is THAT book?
>
> I've seen nothing to suggest that it's noticably better. =A0MSDN, though,
> is full of nonsense. =A0They have a page claiming that parentheses allow
> you to control order of evaluation.
>
I liked the one where they completely run out of
steam on a particular very crucial topic, so they
give you the stunning advice: "Just experiment! Try
various tools to see how they work."

Hmmmm, yes, that IS kind of how I program anyway,
I just press the "any" key and see what happens,
but I'd never thought I'd see "documentation"
encouraging that idiotic behavior...

---
William Ernest Reid

spinoza1111 <spinoza1111@yahoo.com> wrote:
> On May 10, 6:40 am, Seebs <usenet-nos...@seebs.net> wrote:
>>
>> I've seen nothing to suggest that it's noticably better.  MSDN, though,
>> is full of nonsense.  They have a page claiming that parentheses allow
>> you to control order of evaluation.
> 
> Which they do IN PRACTICE. Your vandalism ("sequence points") on
> behalf of vendors can be safely ignored simply by not allowing
> students to use preincrement and postincrement, which were poorly
> thought out by Ritchie at a time when the distinction between value
> and lValue was not clear.

This is a somewhat contrived example (and not a great one), but here is
an ugly and contrived bit of C which shows the problem with predicting
order when the programmer doesn't understand sequence points.  No
preincrements or postincrements to be seen.  In more subtle forms, I
have often had to handle students' confusion on this:

    #include <stdio.h>

    int main(int argc, char *argv[])
    {
        int i;

        printf("%d\n", (i=1)+((i=2)*10)+((i=3)*100));
        printf("%d\n", ((i=1)+((i=2)*10))+((i=3)*100));
        printf("%d\n", (i=1)+(((i=2)*10)+((i=3)*100)));

        return 0;
    }

Now, given the advice that parentheses affects order of evaluation, a
student might expect that the order of evaluation leading to different
results...

Using gcc on Linux gives:

    322
    322
    323

Hmm.  Probably not what the student expected, but clearly the
parentheses have done *something*.  Let's see what happens using gcc
under Cygwin on Windows:

    321
    321
    321

Okay.  At least some of the students might have suspected they'd get
this result.  What about Visual Studio?

    333
    333
    333

Sure, we can teach our students good habits and beg them not to use
global variables or design code with side-effects, but they end up
getting into pickles anyway.

Unless there is an understanding of what guarantees some common standard
offers, they could well be in for a shock later on.

At least gcc gives me a hint I'm being careless:

    % gcc -std=c99 -Wall -pedantic e.c
    e.c: In function ‘main’:
    e.c:7: warning: operation on ‘i’ may be undefined
    e.c:7: warning: operation on ‘i’ may be undefined
    e.c:8: warning: operation on ‘i’ may be undefined
    e.c:8: warning: operation on ‘i’ may be undefined
    e.c:9: warning: operation on ‘i’ may be undefined
    e.c:9: warning: operation on ‘i’ may be undefined

On May 9, 7:47=A0am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> http://catless.ncl.ac.uk/Risks/26.06.html#subj12
>
> This shall shortly also be on the Digest, to where people may respond
> to it. However, responses are competently moderated.

.... Proving, once and for all, that there is such a thing as
"overeducation". Also, that an education, college degree, and hanging
with genius mathematicians doth not one an intelligent person make.

On May 10, 7:02=A0am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On May 9, 8:43=A0pm, "christian.bau" <christian....@cbau.wanadoo.co.uk>
> wrote:
>
> > The risk: Once you write a crap book, there is the risk that it won't
> > be forgotten even ten years later, because some people won't leave it
> > alone. Poor Schildt.
>
> "Crap book" is Nazi language.

Dial the hyperbolator down a few notches; you're liable to burn the
damn thing out running it at 11 all the time.

> To a civilized person, there is no such
> thing. Since truth is always partial outside of pure mathematics, even
> a highly flawed book can be useful.
>

But only as a lesson in how *not* to write a technical reference.  It
is definitely *not* useful for its intended purpose; that is, teaching
people how to program in C.  Given the mistakes that Seebs has
highlighted, it can be actively detrimental.

There is an agreed-upon definition of how the language is *supposed*
to work; that is the language standard.  Most implementations conform
closely to this standard, some moreso than others.  There is some slop
around the edges due to limitations in the implementation environment
or mistakes on the part of the implementor, but on the whole a
conforming compiler *should* accept a conforming program and reject a
non-conforming program.

Additionally, several decades of experience by the C programming
community have identified certain practices that result in reliable,
robust code and therefore should be encouraged, as well as practices
that result in unreliable code and therefore should be discouraged.

The problem with C:TCR is that many of Schildt's explanations run
counter to the language definition; he explains the why's
incorrectly.  He also encourages practices which have been shown to
produce code that is unsafe or unreliable.

On 2010-05-10, John Bode <jfbode1029@gmail.com> wrote:
> But only as a lesson in how *not* to write a technical reference.  It
> is definitely *not* useful for its intended purpose; that is, teaching
> people how to program in C.  Given the mistakes that Seebs has
> highlighted, it can be actively detrimental.

Exactly my point.  There are many books I don't personally like very much,
but which are perfectly suitable to the task for which they are presented.
Even the "For Dummies" books are sometimes useful for a particular task
or purpose, though they aren't usually my favorites.

The complaint about "C: The Complete Reference" isn't just that it maybe
isn't the book I'd most want.  It's that it gets many, many, things wrong,
omits crucial and fundamental bits of the language, and is full of busted
code examples, factually incorrect advice, and worse.

It's not just that it's "too DOS-specific".  It's that the entire explanation
of how to use stdio for character input and output is wrong -- even on DOS
systems.

> The problem with C:TCR is that many of Schildt's explanations run
> counter to the language definition; he explains the why's
> incorrectly.  He also encourages practices which have been shown to
> produce code that is unsafe or unreliable.

Not just the whys, but also the whats.  He's not just giving advice which
misleads users about why things are the way they are; he's flatly
contradicting the way they are *EVEN ON DOS OR WINDOWS SYSTEMS*.  Nilges
has launched a number of apologetics about this book, but none of them address
the fundamental problem -- Schildt clearly doesn't understand how EOF works
in C.

Maybe C's design here is flawed; certainly, there are persuasive arguments to
be had that it should have been done differently.  However, a book on C has
to teach people what will work with C, not what would work with a completely
different language that the author would have preferred.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

> Seebs <usenet-nos...@seebs.net> wrote:
> > MSDN, ... have a page claiming that parentheses allow
> > you to control order of evaluation.

I'm assuming pages like...

  <http://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx>

  "... The following table summarizes the precedence and
  associativity (the order in which the operands are
  evaluated)..."

spinoza1111 <spinoza1...@yahoo.com> wrote:
> Which they do IN PRACTICE.

In some languages, but not in C, although many naive students
believe they do.

> ... ("sequence points") ... can be safely ignored

Indeed. Sequence points are not relevant as they relate to the
completion of side effects, not order of evaluation which is
explicitly unspecified in C, both in theory and in practice...

  6.5p3 "The grouping of operators and operands is indicated
  by the syntax. Except as specified later (for the function-
  call (), &&, ||, ?:, and comma operators), the order of
  evaluation of subexpressions and the order in which side
  effects take place are both unspecified."

--
Peter

On 2010-05-11, Peter Nilsson <airia@acay.com.au> wrote:
> I'm assuming pages like...
>
>  <http://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx>
>
>   "... The following table summarizes the precedence and
>   associativity (the order in which the operands are
>   evaluated)..."

There was a page that said specifically that you could use ()s to
change the order in which things were evaluated.  This is, of course,
not even true of Microsoft's compiler.

> spinoza1111 <spinoza1...@yahoo.com> wrote:
>> Which they do IN PRACTICE.

> In some languages, but not in C, although many naive students
> believe they do.

Indeed.  We had a discussion on this not that long ago, in which specific
examples were brought forth showing that no such ordering occurred.

>> ... ("sequence points") ... can be safely ignored

> Indeed. Sequence points are not relevant as they relate to the
> completion of side effects, not order of evaluation which is
> explicitly unspecified in C, both in theory and in practice...

Interestingly, Schildt gets this mostly right -- he states it correctly
once in the 3rd edition, then offers an "example" which is completely wrong
and does not work as described.  In the 4th edition, he removed the example
without offering a replacement, probably because he couldn't figure out
how to make a working one.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On May 11, 2:56=A0am, John Bode <jfbode1...@gmail.com> wrote:
> On May 10, 7:02=A0am, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
> > On May 9, 8:43=A0pm, "christian.bau" <christian....@cbau.wanadoo.co.uk>
> > wrote:
>
> > > The risk: Once you write a crap book, there is the risk that it won't
> > > be forgotten even ten years later, because some people won't leave it
> > > alone. Poor Schildt.
>
> > "Crap book" is Nazi language.
>
> Dial the hyperbolator down a few notches; you're liable to burn the
> damn thing out running it at 11 all the time.

It's not hyperbolic. People who like Seebach focus on other people's
putative errors while ignoring their own incompetence are just-add-
water Nazis in that under stress they look instinctively for
scapegoats. Fascism is so evil (most people, faced with the choice of
only Fascism or Communism, choose Communism) that its preconditions
must be radically addressed and not ignored...for much the same reason
we must not allow people like Seebach, whose praxis and theory creates
the preconditions for massive errors, to pretend that they give a
flying fuck about software reliability...because they do not.
Seebach's own code (including queue.c after two months work) is
riddled with errors. All he cares about is a massive tu quoque which
shows that he has no competition.
>
> > To a civilized person, there is no such
> > thing. Since truth is always partial outside of pure mathematics, even
> > a highly flawed book can be useful.
>
> But only as a lesson in how *not* to write a technical reference. =A0It
> is definitely *not* useful for its intended purpose; that is, teaching
> people how to program in C. =A0Given the mistakes that Seebs has
> highlighted, it can be actively detrimental.

How would you know? Use scientific method, Mr. Science!

"I have a MASTER'S degree. In SCIENCE!"

That is: Seebach uses (poor) deduction from the Standard to conclude
the lemma "Herb is wrong on Ten Thousand Things". He then uses as an
axiom that "if the teacher makes mistakes, the students will not
learn". This axiom is questionable, since in my experience as a
teacher, learning is a mutual enquiry, not the old, and somewhat
discredited model, of "teacher speaks naught but the truth, students
write it down".

Dweebach then deductively concludes that "Herb is a bad teacher".

This happens to contradict Dweebach's claim that "Herb is a clear
writer", deductively, since we know that clarity leads to
understanding, and understanding to justified true belief, which has a
lot to do with education.

But that aside...Dweebach has NEVER presented any empirical evidence
to CONFIRM his deductive reasoning, and this is mediaeval, syllogistic
reasoning!

Dweebach and friends are constantly speaking of the misled "newbie" as
a complete abstraction. Since Dweebach and friends seem to me
precisely the sort of loudmouths who drive people away, this is
likely.

The only empirical evidence is in fact Schildt's sales figures, and
they contradict Dweebach's deductive reasoning!

>
> There is an agreed-upon definition of how the language is *supposed*
> to work; that is the language standard. =A0Most implementations conform
> closely to this standard, some moreso than others. =A0There is some slop
> around the edges due to limitations in the implementation environment
> or mistakes on the part of the implementor, but on the whole a
> conforming compiler *should* accept a conforming program and reject a
> non-conforming program.

But then we learn that conformant compilers are in fact impossible in
C, because of aliasing and because the standard left too much
undefined...a mystery.
>
> Additionally, several decades of experience by the C programming
> community have identified certain practices that result in reliable,
> robust code and therefore should be encouraged, as well as practices
> that result in unreliable code and therefore should be discouraged.
>
> The problem with C:TCR is that many of Schildt's explanations run
> counter to the language definition; he explains the why's
> incorrectly. =A0He also encourages practices which have been shown to
> produce code that is unsafe or unreliable.

The C community is not known, in fact, to have met Dijkstra's
challenge thrown down two years before Dijkstra's death: to not make a
mess of it. Therefore, I do not accept their standing in judging
Schildt.

On May 11, 3:00=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-05-11, Peter Nilsson <ai...@acay.com.au> wrote:
>
> > I'm assuming pages like...
>
> > =A0<http://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx>
>
> > =A0 "... The following table summarizes the precedence and
> > =A0 associativity (the order in which the operands are
> > =A0 evaluated)..."
>
> There was a page that said specifically that you could use ()s to
> change the order in which things were evaluated. =A0This is, of course,
> not even true of Microsoft's compiler.

You're lying. Here's WHAT YOU SAID:

"This one is just gob-smackingly bad. Schildt has no concept of what
parentheses do. He writes, on page 57:

'Parentheses are operators that increase the precedence of the
operations inside them.'"

Which is what they are. Since you never took a comp sci 101 class,
much less compiler design, you simply seem not to know that the
semantics of a usable language are defined for NON-OPTIMIZED code,
since it is the job of the optimizer to preserve semantics while
changing order of execution as necessary as possible.

Herb is correct. This is what parentheses do. The optimizer is
entitled to change the order of evaluation if the precedence is
preserved, and that remains the same true fact if you switch "order of
evaluation" and "precedence", because that phrase and that word merely
disambiguate the mathematical meaning of the code, and how it is
executed.

spinoza1111 wrote:
> On May 11, 3:00 pm, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2010-05-11, Peter Nilsson <ai...@acay.com.au> wrote:
>>
>>> I'm assuming pages like...
>>>  <http://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx>
>>>   "... The following table summarizes the precedence and
>>>   associativity (the order in which the operands are
>>>   evaluated)..."
>> There was a page that said specifically that you could use ()s to
>> change the order in which things were evaluated.  This is, of course,
>> not even true of Microsoft's compiler.
> 
> You're lying.

Do you mean there is no such page, or do you mean that Microsoft's 
compiler allows the control of evaluation order via parentheses?


> Here's WHAT YOU SAID:
> 
> "This one is just gob-smackingly bad. Schildt has no concept of what
> parentheses do. He writes, on page 57:
> 
> 'Parentheses are operators that increase the precedence of the
> operations inside them.'"
> 
> Which is what they are.  Since you never took a comp sci 101 class,
> much less compiler design, you simply seem not to know that the
> semantics of a usable language are defined for NON-OPTIMIZED code,
> since it is the job of the optimizer to preserve semantics while
> changing order of execution as necessary as possible.
> 
> Herb is correct. This is what parentheses do. The optimizer is
> entitled to change the order of evaluation if the precedence is
> preserved,

....or even if it isn't. Between consecutive sequence points, the 
implementation is entitled to use any order of evaluation in likes.

> and that remains the same true fact if you switch "order of
> evaluation" and "precedence", because that phrase and that word merely
> disambiguate the mathematical meaning of the code, and how it is
> executed.

Precedence bears only the most tenuous relation to order of evaluation. 
Precedence is about which operands are associated with which operators, 
whereas order of evaluation is all about the order in which things are 
evaluated. These are very far from being the same thing.

In code where x, y, and z are functions that print their own name and 
then (respectively) return 2, 3, 5, the expression:

w = x() + y() * z();

can result in the printing of any one of xyz, xzy, yxz, yzx, zxy, or 
zyx, and the programmer exercises no control over which of these is 
printed, but w *must* get the value 17.

If we add parentheses:

w = x() + (y() * z());

nothing changes. Most especially, there is no requirement on the 
implementation to print either yzx or zyx rather than any of the other 
possible permutations. If we add the parentheses elsewhere instead:

w = (x() + y()) * z();

the only thing that changes is that now w must be given the value 30, 
not the value 17. The parentheses do not impose a particular evaluation 
order on the code, so we still have six possible outcomes for the print. 
Obviously the implementation must evaluate x(), y(), and z() in *some* 
order, but that order is entirely up to the implementation, and 
parentheses offer us no control over that order.

If order of evaluation matters, we enforce it via sequence points. 
That's what they're for.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

On 2010-05-11, Richard Heathfield <rjh@see.sig.invalid> wrote:
> Do you mean there is no such page, or do you mean that Microsoft's 
> compiler allows the control of evaluation order via parentheses?

It's hard to say.

In any event:

http://msdn.microsoft.com/en-us/library/126fe14k%28vs.71%29.aspx

	"Operators in the same segment of the table have equal
	precedence and are evaluated left to right in an expression
	unless explicitly forced by parentheses."
	
Or

http://msdn.microsoft.com/en-us/library/2bxt6kc4%28VS.80%29.aspx

	"Expressions with higher-precedence operators are evaluated
	first."

This is, of course, not particularly correct.

Imagine:
	#include <stdio.h>
	int a(void) { putc('a'); return 1; }
	int b(void) { putc('b'); return 2; }
	int c(void) { putc('c'); return 3; }
	int main(void) {
		printf("\n%d\n", a() + b() * c());
		return 0;
	}

Now, we know with confidence that this will print some ordering of
a, b, and c, then a newline, then 7, then a nother newline.

But we don't know what order a, b, and c will come out in.  MSDN claims
that b() and c() have to be evaluated first, because their expression
has a higher-precedence operator, but this is not always the case.
Similarly, the first quote suggests that b() should be evaluated before
c() because it should be "evaluated left to right".

The problem is that MSDN's pages frequently talk about order of evaluation
when they mean grouping of expressions.

[seebs, in C:TCN]

>> 'Parentheses are operators that increase the precedence of the
>> operations inside them.'"

[spinny]
>> Herb is correct. This is what parentheses do. The optimizer is
>> entitled to change the order of evaluation if the precedence is
>> preserved,

> ...or even if it isn't. Between consecutive sequence points, the 
> implementation is entitled to use any order of evaluation in likes.

But really, they haven't changed the precedence of anything.  They've
grouped a subexpression.

The key point, of course, is to remember that Schildt's example for this was:

	x = *p++ * (*p);
which he "corrects" to:
	x = *p * (*p++);

First off, the parentheses are irrelevant in both cases.  Secondly, nothing
in here makes any difference; there's no reason to expect one of these to
work better than the other.

So Schildt's discussion of order of evaluation remains nonsense, too.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs <usenet-nospam@seebs.net> writes:
> On 2010-05-11, Richard Heathfield <rjh@see.sig.invalid> wrote:
[...]
> [seebs, in C:TCN]
>
>>> 'Parentheses are operators that increase the precedence of the
>>> operations inside them.'"

[The above is a quotation from Schildt's book.]

> [spinny]
>>> Herb is correct. This is what parentheses do. The optimizer is
>>> entitled to change the order of evaluation if the precedence is
>>> preserved,
>
>> ...or even if it isn't. Between consecutive sequence points, the 
>> implementation is entitled to use any order of evaluation in likes.
>
> But really, they haven't changed the precedence of anything.  They've
> grouped a subexpression.

Schildt's description, though it's badly worded, isn't necessarily
entirely wrong.  Parentheses do have to do with precedence.  Perhaps a
better way to say it is that parentheses themselves have very high
precedence.  (Of course the C standard doesn't discuss this in terms of
precedence, but it's not unreasonable to apply the concept.)

For example, in
    x + y * z
"*" has higher precedence than "+"; in
    (x + y) * z
"()" has higher precedence than either "+" or "*".

> The key point, of course, is to remember that Schildt's example for this was:
>
> 	x = *p++ * (*p);
> which he "corrects" to:
> 	x = *p * (*p++);
>
> First off, the parentheses are irrelevant in both cases.  Secondly, nothing
> in here makes any difference; there's no reason to expect one of these to
> work better than the other.
>
> So Schildt's discussion of order of evaluation remains nonsense, too.

Exactly.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On May 11, 1:06=A0pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On May 11, 2:56=A0am, John Bode <jfbode1...@gmail.com> wrote:
>
> > On May 10, 7:02=A0am, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
> > > On May 9, 8:43=A0pm, "christian.bau" <christian....@cbau.wanadoo.co.u=
k>
> > > wrote:
>
> > > > The risk: Once you write a crap book, there is the risk that it won=
't
> > > > be forgotten even ten years later, because some people won't leave =
it
> > > > alone. Poor Schildt.
>
> > > "Crap book" is Nazi language.
>
> > Dial the hyperbolator down a few notches; you're liable to burn the
> > damn thing out running it at 11 all the time.
>
> It's not hyperbolic. People who like Seebach focus on other people's
> putative errors while ignoring their own incompetence are just-add-
> water Nazis in that under stress they look instinctively for
> scapegoats. Fascism is so evil (most people, faced with the choice of
> only Fascism or Communism, choose Communism) that its preconditions
> must be radically addressed and not ignored...for much the same reason
> we must not allow people like Seebach, whose praxis and theory creates
> the preconditions for massive errors, to pretend that they give a
> flying fuck about software reliability...because they do not.
> Seebach's own code (including queue.c after two months work) is
> riddled with errors. All he cares about is a massive tu quoque which
> shows that he has no competition.
>

Dude.  Get help.  Your current therapist is doing you no favors.

John Bode <jfbode1029@gmail.com> writes:
> On May 11, 1:06 pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
[...]
>
> Dude.  Get help.  Your current therapist is doing you no favors.

Dude.  People have been trying to communicate rationally with
"spinoza1111" for many years.  It never works.  Give it up.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Richard Heathfield <rjh@see.sig.invalid> writes:
<snip>
> ...or even if it isn't. Between consecutive sequence points, the
> implementation is entitled to use any order of evaluation in likes.

This is not wrong but could very easily be misconstrued.  The sequence
points don't sit there like immovable objects -- the implementation can
move some of them around (in time) because they are attached to certain
code constructs.  They move with these construct if the implementation
reorders their evaluation.

<snip>
> In code where x, y, and z are functions that print their own name and
> then (respectively) return 2, 3, 5, the expression:
>
> w = x() + y() * z();
>
> can result in the printing of any one of xyz, xzy, yxz, yzx, zxy, or
> zyx, and the programmer exercises no control over which of these is
> printed, but w *must* get the value 17.

Your example (as I am sure you know) is littered with sequence points.
We can "see" four but there are others at the return from each function
call and associated with whatever library function does the actual
printing.  Most of these can be moved about depending on the order of
evaluation chosen by the implementation.

<snip>
> If order of evaluation matters, we enforce it via sequence
> points. That's what they're for.

Sequence points alone can't help (as your own example shows).  The order
is controlled but using constructs which the C language defines (or
should define) as ordered: the ordering between consecutive statements
for example; and the special wording given for some operators (comma,
&&, || and ?:).  That these cases also coincide with sequence points
makes them useful but it is not what makes them ordered.

At the risk of labouring this rather small point, one can imagine both
a C-like language where all sorts of constructs are ordered but with no
sequence points, and one where everything has a sequence point but no
order of evaluation is defined -- even between statements!  Neither
language would be useful, of course.  The utility of C comes from the
interplay between the limited permission to reorder and the relative
abundance of sequence points which allow you know what must have
happened (and to legally observe these effects).

-- 
Ben.

On May 12, 4:06=A0am, Keith Thompson <ks...@mib.org> wrote:
> Seebs <usenet-nos...@seebs.net> writes:
> > On 2010-05-11, Richard Heathfield <r...@see.sig.invalid> wrote:
> [...]
> > [seebs, in C:TCN]
>
> >>> 'Parentheses are operators that increase the precedence of the
> >>> operations inside them.'"
>
> [The above is a quotation from Schildt's book.]
>
> > [spinny]
> >>> Herb is correct. This is what parentheses do. The optimizer is
> >>> entitled to change the order of evaluation if the precedence is
> >>> preserved,
>
> >> ...or even if it isn't. Between consecutive sequence points, the
> >> implementation is entitled to use any order of evaluation in likes.
>
> > But really, they haven't changed the precedence of anything. =A0They've
> > grouped a subexpression.
>
> Schildt's description, though it's badly worded, isn't necessarily
> entirely wrong. =A0

Oh thanks mighty C authority

> Parentheses do have to do with precedence. =A0Perhaps a
> better way to say it is that parentheses themselves have very high
> precedence. =A0

A remarkably ignorant statement, since in accepted usage in the
computer science community, only operators can have precedence, and
parentheses are not operators.

> (Of course the C standard doesn't discuss this in terms of
> precedence, but it's not unreasonable to apply the concept.)
>
> For example, in
> =A0 =A0 x + y * z
> "*" has higher precedence than "+"; in
> =A0 =A0 (x + y) * z
> "()" has higher precedence than either "+" or "*".

This makes no sense whatsoever. The parentheses are not evaluated. If
you translate the expression "(x + y) * z" to suffix notation (xy+z*)
they go away.

Operator precedence is in fact defined only for infix expressions in
the ABSENCE of parentheses, and in ordinary math and compsci, the
addition and subtraction operators have higher precedence than the
multiplication and division operators, which was based on praxis in
high school algebra. Therefore, your statement gives evidence that you
flunked high school algebra. WTF do you think you are doing at Nokia?


>
> > The key point, of course, is to remember that Schildt's example for thi=
s was:
>
> > =A0 =A0x =3D *p++ * (*p);
> > which he "corrects" to:
> > =A0 =A0x =3D *p * (*p++);
>
> > First off, the parentheses are irrelevant in both cases. =A0Secondly, n=
othing
> > in here makes any difference; there's no reason to expect one of these =
to
> > work better than the other.
>
> > So Schildt's discussion of order of evaluation remains nonsense, too.
>
> Exactly.

I'm afraid that while Schildt may have been at times confused by an
artifact which was incompetently designed, your discussion, Mr.
Thompson, exhibits a frightening lack of comprehension of the
scientific basis of your profession.

It is remarkable how foully people who misuse "terminology" are
treated here by people who in Seebach's case, lack, and exhibit lack
of, computer science education, and in your case also eshibit this
lack.

During the later part of my programming career, earlier in this
decade, I noticed that actual programmers and their managers were
forever finding excuses not to program in the USA. This was because
for years, management had dismissed the scientific theory in favor of
snake oil, and it was confirmed by articles in the New York Times:
that most American programmers simply do not code much. They attend
meetings, they read and write "white papers", those famous documents,
carefully purged of critical thought, with a subtly racist name.

They occasionally change a line of code and almost as often get it
wrong. They write shell procedures or vanity C with unnecessarily
unstructured fallthrough.

They spend hours gossiping and backbiting, online and in meatspace,
and on the phone to real estate brokers.

When they are laid off, nothing much happens apart from the stock
price increase because all the work is being done by my former
coworkers in Shenzen, and in India.

Anyone who can say with a straight face that parentheses have
precedence is a clown.

And anyone who mounts a fifteen year campaign of personal destruction
against a harmless computer author is an evil clown.

I see another comp.risks submission: the RISKS of programmer
incompetence. Don't worry, I won't name names, whether of individuals
or companies. But part of my article will be based on what I've seen
here.

However, at this time, I have taken a break to write a Shakespearean
play about the British election, "The Well-Hung Election, or, Brown
Goeth Down to China Town". I am applying what I know about prosody.
People here are welcome to read it at
http://spinoza1111.wordpress.com/2010/05/07/a-newly-discoverd-play-by-the-i=
mmortal-shakespeare-who-turns-out-to-be-literally-immortal-alive-and-well-i=
f-rather-shady-in-london-today/.
Here's a sample:

Brown: Varlet, scum, Nancy boy, loser,
And whatever other name may not unbecome
My high and palmy state, tho=92 it be thus destroy=92d
(For even as men remember=92d Rome they will bewail
The loss of New Labour and its grand design)
Be thou call=92d. Out of my sight! Thou dost infect mine eyes:
You incompetent Piece of Matter Fecal,
You toad-eating scum of the green-mantl=92d Pond,
You block, you stone, you worse than senseless thing,
Thou hast stol=92n the election and I am no longer King.

Aide Secundus:What, King? Thou weren=92t elected
But King thou never wert, or my name is Bert
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org =A0<http://www.ghoti.net/~=
kst>
> Nokia
> "We must do something. =A0This is something. =A0Therefore, we must do thi=
s."
> =A0 =A0 -- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson <ks...@mib.org> wrote:
> Seebs <usenet-nos...@seebs.net> writes:
> > > spinoza1111 wrote:
> > > > 'Parentheses are operators that increase the precedence
> > > > of the operations inside them.'"
>
> [The above is a quotation from Schildt's book.]
>
> > > > Herb is correct.

He's incorrect in describing parentheses as operators.

> > > > This is what parentheses do.
> >
> > But really, they haven't changed the precedence of
> > anything. =A0They've grouped a subexpression.

And in so doing, increased the precedence of each operator
therein. Each nesting effectively introduces an additional
precedence tier, recursively for each level of nesting.

> Schildt's description, though it's badly worded,
> isn't necessarily entirely wrong.

It's only wrong in that it calls (grouping) parentheses
operators when they are just syntax, just as the comma that
separates function arguments are syntax, not operators.

>=A0Parentheses do have to do with precedence.

They affect the precedence of operators within them.

>=A0Perhaps a better way to say it is that parentheses
> themselves have very high precedence.

That is common and tends to be easier to understand
than recursively nested precedence tables.

>=A0(Of course the C standard doesn't discuss this in terms
> of precedence,

As the footnote says, the intent is that precedence is
implied by the grammer. The nesting of precedence tiers
is therefore also implied by the grammar.

> but it's not unreasonable to apply the concept.)

It's not confusing, but it's not actually right. Just as
saying 'unsigned integers wrap on overflow' is not confusing,
but not actually right.

> For example, in
> =A0 =A0 x + y * z
> "*" has higher precedence than "+"; in
> =A0 =A0 (x + y) * z
> "()" has higher precedence than either "+" or "*".

When in reality, the parentheses have given the contained "+"
a higher precedence than the outer "*".

--
Peter

On 2010-05-13, Peter Nilsson <airia@acay.com.au> wrote:
> When in reality, the parentheses have given the contained "+"
> a higher precedence than the outer "*".

I don't think that's an accurate description.  It's not horribly wrong,
but I think it's misleading.  The + has the same precedence it has always
had -- it's just that it is now in a smaller sub-expression.

In
	foo(a + b) * 3;
foo() isn't changing the precedence of + -- it's just moving the + into
a separate expression which has a rule other than precedence defining
its boundaries.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Peter Nilsson <airia@acay.com.au> writes:
> Keith Thompson <ks...@mib.org> wrote:
>> Seebs <usenet-nos...@seebs.net> writes:
>> > > spinoza1111 wrote:
>> > > > 'Parentheses are operators that increase the precedence
>> > > > of the operations inside them.'"
>>
>> [The above is a quotation from Schildt's book.]
>>
>> > > > Herb is correct.
>
> He's incorrect in describing parentheses as operators.
[...]

Agreed, the standard doesn't describe parentheses as operators.
But it could have done so, with no real change in meaning.
(Think of them as "unary outfix", if that's a word.)

Personally, I'm more comfortable thinking of parentheses as
operators than "." or "->".  Still, it's generally better to
follow the terminology used by the standard.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On May 13, 12:04=A0pm, Keith Thompson <ks...@mib.org> wrote:
> Peter Nilsson <ai...@acay.com.au> writes:
> > Keith Thompson <ks...@mib.org> wrote:
> >> Seebs <usenet-nos...@seebs.net> writes:
> >> > > spinoza1111 wrote:
> >> > > > 'Parentheses are operators that increase the precedence
> >> > > > of the operations inside them.'"
>
> >> [The above is a quotation from Schildt's book.]
>
> >> > > > Herb is correct.
>
> > He's incorrect in describing parentheses as operators.
>
> [...]
>
> Agreed, the standard doesn't describe parentheses as operators.

I don't give a damn about what the standard says. It was deliberately
given over for drafting to incompetents so as to avoid compiler
change.

> But it could have done so, with no real change in meaning.
> (Think of them as "unary outfix", if that's a word.)

"Unary outfix", if that's a word?
This is the ultima Thule of the absurd
Is there no depth to which you will not sink?
Were I but a drinking man, it would be time to have a drink.

Parentheses are not operators. Operators are compiled into code;
parentheses are used, and thrown away, by the compiler.


>
> Personally, I'm more comfortable thinking of parentheses as
> operators than "." or "->". =A0Still, it's generally better to
> follow the terminology used by the standard.

It is always and everywhere a mark of Idiocy
To use the word "terminology".
The reason is simple and easy to understand
At least to a member of the species, Man.
"Terminology" is swot by the low and self-taught
In order to get jobs accounts to tot or copies to jot
It alienates the person from the word:
For it's obvious to the veriest bird,
That to study words is called "words", books, and reading
An occupation for the man of letters of excellent breeding
Whereas to mindlessly memorize "material"
(A sort of grey paste that's beginning to smell,
For that what the word used by teachers implies:
In "material" find the death of education, of joy and surprise)
To start again, to mindlessly swot by rote "material"
Is the mark of the fool and soon to be knave, tho' drest Swell
In clothes of the City from Versace or Hugo Boss
Underneath the swot, the geek, the lager lout, a loss
For all that come near him, be it colleague or lass
He's really learned nothing...he remaineth an Ass
Who can say from his perch at some corporate stool
"Parentheses are operators", is merely a Fool.

>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org =A0<http://www.ghoti.net/~=
kst>
> Nokia
> "We must do something. =A0This is something. =A0Therefore, we must do thi=
s."
> =A0 =A0 -- Antony Jay and Jonathan Lynn, "Yes Minister"

On May 13, 12:04=A0pm, Keith Thompson <ks...@mib.org> wrote:
> Peter Nilsson <ai...@acay.com.au> writes:
> > Keith Thompson <ks...@mib.org> wrote:
> >> Seebs <usenet-nos...@seebs.net> writes:
> >> > > spinoza1111 wrote:
> >> > > > 'Parentheses are operators that increase the precedence
> >> > > > of the operations inside them.'"
>
> >> [The above is a quotation from Schildt's book.]
>
> >> > > > Herb is correct.
>
> > He's incorrect in describing parentheses as operators.
>
> [...]
>
> Agreed, the standard doesn't describe parentheses as operators.
> But it could have done so, with no real change in meaning.
> (Think of them as "unary outfix", if that's a word.)
>
> Personally, I'm more comfortable thinking of parentheses as
> operators than "." or "->". =A0Still, it's generally better to
> follow the terminology used by the standard.
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org =A0<http://www.ghoti.net/~=
kst>
> Nokia
> "We must do something. =A0This is something. =A0Therefore, we must do thi=
s."
> =A0 =A0 -- Antony Jay and Jonathan Lynn, "Yes Minister"

Schildt harmlessly refers to parentheses as "operators" where the noun
clearly means "anything that is not a symbol", as it would in a
classroom of junior programmers unprepared by university level
training in computer science. Keith, who should know better,
misinterprets this as meaning that parentheses are "operators" in the
narrower sense. He's unable to see, as is Seebach unable, that there's
three sorts of "language games" going on.

The first is the language game in which people who haven't taken
computer science need gradually to form mental "sets" and groupings of
concepts which only approximate the rigid taxonomy of formal computer
science.

The second is that of computer science which (because parentheses are
provably unnecessary) no longer calls parentheses operators.

The third is the debased parody of computer science language which
uneducated people pick up inside corporations, and it is what Seebach
and Kiki use. It is disturbingly similar to the examples Orwell gives
of poor English in his essay "Politics and the English Language", as
used by half-educated Stalinist thugs. This is because the writer
never takes responsibility for what goes on inside a phrase like
"outfix operator".

Real attempts at understanding (Herb's clarity) vary their language
game inside of the text, but people untrained in critical reading such
as Dweebach can't follow the shifts, especially when they are
mollycoddled little shits protected from participating in the real
world by white racism.

Herb knows that in the sense of compiling to an operation, a
parenthesis is not an operator. But from the standpoint of lexical
analysis, with which he's familiar and Dweebach isn't, it is a
syntactical operator. And, of course, it increases the precedence of
the semantic ops inside of it.

Franz Fanon long ago recognized the way in which lower middle class
little shits of *pieds noirs* used concepts rigidly: "look, a Negro".
This language autistically assumes that there's only one language
game. It lacks a human ability: to metalinguistically detect shifts in
language games overall.

There's Nothing Sacred about "operators". Humpty Dumpty was right.
When we use words they mean exactly what we intend them to mean: no
more and no less. The real action takes place in the air between two
people who are in purity of heart trying to solve a problem such as
their enmity or conflict. If they are as here trying to destroy the
other person, we may as well meet, in meat space, and have a fight.
I'm game.

On May 12, 9:50=A0pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On May 12, 4:06=A0am, Keith Thompson <ks...@mib.org> wrote:
>
>
>
>
>
> > Seebs <usenet-nos...@seebs.net> writes:
> > > On 2010-05-11, Richard Heathfield <r...@see.sig.invalid> wrote:
> > [...]
> > > [seebs, in C:TCN]
>
> > >>> 'Parentheses are operators that increase the precedence of the
> > >>> operations inside them.'"
>
> > [The above is a quotation from Schildt's book.]
>
> > > [spinny]
> > >>> Herb is correct. This is what parentheses do. The optimizer is
> > >>> entitled to change the order of evaluation if the precedence is
> > >>> preserved,
>
> > >> ...or even if it isn't. Between consecutive sequence points, the
> > >> implementation is entitled to use any order of evaluation in likes.
>
> > > But really, they haven't changed the precedence of anything. =A0They'=
ve
> > > grouped a subexpression.
>
> > Schildt's description, though it's badly worded, isn't necessarily
> > entirely wrong. =A0
>
> Oh thanks mighty C authority
>
> > Parentheses do have to do with precedence. =A0Perhaps a
> > better way to say it is that parentheses themselves have very high
> > precedence. =A0
>
> A remarkably ignorant statement, since in accepted usage in the
> computer science community, only operators can have precedence, and
> parentheses are not operators.
>
> > (Of course the C standard doesn't discuss this in terms of
> > precedence, but it's not unreasonable to apply the concept.)
>
> > For example, in
> > =A0 =A0 x + y * z
> > "*" has higher precedence than "+"; in
> > =A0 =A0 (x + y) * z
> > "()" has higher precedence than either "+" or "*".
>
> This makes no sense whatsoever. The parentheses are not evaluated. If
> you translate the expression "(x + y) * z" to suffix notation (xy+z*)
> they go away.
>
> Operator precedence is in fact defined only for infix expressions in
> the ABSENCE of parentheses, and in ordinary math and compsci, the
> addition and subtraction operators have higher precedence than the
> multiplication and division operators, which was based on praxis in
> high school algebra. Therefore, your statement gives evidence that you
> flunked high school algebra. WTF do you think you are doing at Nokia?
>
>
>
> > > The key point, of course, is to remember that Schildt's example for t=
his was:
>
> > > =A0 =A0x =3D *p++ * (*p);
> > > which he "corrects" to:
> > > =A0 =A0x =3D *p * (*p++);
>
> > > First off, the parentheses are irrelevant in both cases. =A0Secondly,=
 nothing
> > > in here makes any difference; there's no reason to expect one of thes=
e to
> > > work better than the other.
>
> > > So Schildt's discussion of order of evaluation remains nonsense, too.
>
> > Exactly.
>
> I'm afraid that while Schildt may have been at times confused by an
> artifact which was incompetently designed, your discussion, Mr.
> Thompson, exhibits a frightening lack of comprehension of the
> scientific basis of your profession.
>
> It is remarkable how foully people who misuse "terminology" are
> treated here by people who in Seebach's case, lack, and exhibit lack
> of, computer science education, and in your case also eshibit this
> lack.
>
> During the later part of my programming career, earlier in this
> decade, I noticed that actual programmers and their managers were
> forever finding excuses not to program in the USA. This was because
> for years, management had dismissed the scientific theory in favor of
> snake oil, and it was confirmed by articles in the New York Times:
> that most American programmers simply do not code much. They attend
> meetings, they read and write "white papers", those famous documents,
> carefully purged of critical thought, with a subtly racist name.
>
> They occasionally change a line of code and almost as often get it
> wrong. They write shell procedures or vanity C with unnecessarily
> unstructured fallthrough.
>
> They spend hours gossiping and backbiting, online and in meatspace,
> and on the phone to real estate brokers.
>
> When they are laid off, nothing much happens apart from the stock
> price increase because all the work is being done by my former
> coworkers in Shenzen, and in India.
>
> Anyone who can say with a straight face that parentheses have
> precedence is a clown.
>
> And anyone who mounts a fifteen year campaign of personal destruction
> against a harmless computer author is an evil clown.
>
> I see another comp.risks submission: the RISKS of programmer
> incompetence. Don't worry, I won't name names, whether of individuals
> or companies. But part of my article will be based on what I've seen
> here.
>
> However, at this time, I have taken a break to write a Shakespearean
> play about the British election, "The Well-Hung Election, or, Brown
> Goeth Down to China Town". I am applying what I know about prosody.
> People here are welcome to read it athttp://spinoza1111.wordpress.com/201=
0/05/07/a-newly-discoverd-play-by....
> Here's a sample:
>
> Brown: Varlet, scum, Nancy boy, loser,
> And whatever other name may not unbecome
> My high and palmy state, tho=92 it be thus destroy=92d
> (For even as men remember=92d Rome they will bewail
> The loss of New Labour and its grand design)
> Be thou call=92d. Out of my sight! Thou dost infect mine eyes:
> You incompetent Piece of Matter Fecal,
> You toad-eating scum of the green-mantl=92d Pond,
> You block, you stone, you worse than senseless thing,
> Thou hast stol=92n the election and I am no longer King.
>
> Aide Secundus:What, King? Thou weren=92t elected
> But King thou never wert, or my name is Bert
>
>
>
>
>
> > --
> > Keith Thompson (The_Other_Keith) ks...@mib.org =A0<http://www.ghoti.net=
/~kst>
> > Nokia
> > "We must do something. =A0This is something. =A0Therefore, we must do t=
his."
> > =A0 =A0 -- Antony Jay and Jonathan Lynn, "Yes Minister"

I missed something here: where Herb, and not Kiki, was the first to
say that the parenthesis is an operator. That's something I or Dan
Appleman, would not have let stand in "Build Your Own .Net Language
and Compiler".

Herb, as I have said, uses an oral/informal style of discourse which
is far more clear than the nonsense posted in this thread by Kiki and
by Dweebach. You have to "listen" to it with the same sort of charity
and respect for one's elders I was able to display towards my
professor and Sherman, the author of my 7094 centric compsci text, in
1970. As you "listen", you form TEMPORARY concepts which being
temporary are soft, and further malleable.

Whereas people like Seebach, who has confessed to Autism, are debased
and brittle old men long before their time: if on one page Herb means
by "operator", "something that is not a variable", this must be cast
in stone.

Kiki's problem is that he wants to find out some way in which a
parenthesis could ALWAYS be an operator, and nobody who knows Polish
notation would regard this as perspicuous.

Seebs <usenet-nospam@seebs.net> writes:

> On 2010-05-13, Peter Nilsson <airia@acay.com.au> wrote:
>> When in reality, the parentheses have given the contained "+"
>> a higher precedence than the outer "*".
>
> I don't think that's an accurate description.  It's not horribly wrong,
> but I think it's misleading.  The + has the same precedence it has always
> had -- it's just that it is now in a smaller sub-expression.
>
> In
> 	foo(a + b) * 3;
> foo() isn't changing the precedence of + -- it's just moving the + into
> a separate expression which has a rule other than precedence defining
> its boundaries.

However, one could parse the expression using Peter's rule.  Lets say we
give every 'naked' operator a precedence in [0,100): ',' is 0, = is 1,
and so one.  For every nesting construct (F(...), A[...] and plain
(...)) we add 10**(n+1) to the precedence of the enclosed operators
where n is the nesting level.  We could then remove the ()s and []s and
parse the expression using operator precedence alone.  We'd have to
leave some residual sign for the function call and subscript operators.

   (a + 1)[(x + 3)*2]

Would become:

   a {+111} 1 {[]14} x {+1011} 2 {*112} 2

using <OP PREC> to denote operator OP with precedence PREC.  Thinking a
little about the details, I would not be surprised if ?: needed a left
and right precedence, but that not uncommon is such grammars.

I don't think there's much merit in this as a practical method, but it
never hurts to have more ways to describe things.  Some people may find
it a useful way to think about parentheses.

-- 
Ben.

Seebs <usenet-nos...@seebs.net> wrote:
> Peter Nilsson <ai...@acay.com.au> wrote:
> > When in reality, the parentheses have given the contained
> > "+" a higher precedence than the outer "*".
>
> I don't think that's an accurate description.

In what way is it inaccurate?

>=A0It's not horribly wrong,

How is it wrong in _any_ way, other than not being the way
you would describe it?

> but I think it's misleading.

That you find it misleading does not make it wrong. Perhaps
you you only find it misleading because you've grown up with
an alternative premice that you can't shake.

>=A0The + has the same precedence it has always had
> -- it's just that it is now in a smaller sub-expression.

If you play any trump card games, you can think of it in
terms that 10 beats 9, which beats 8, which beats 7 etc...
However, a 9 of hearts may trump a 10 of spades. It's still
a 9 and it's still lower than a 10, but being a high suit,
it can sometimes beat a 10 of any lower suit. [Of course,
the C grammer is not limited to 4 suits of operators. ;-]

--
Peter

On 2010-05-13, Peter Nilsson <airia@acay.com.au> wrote:
> Seebs <usenet-nos...@seebs.net> wrote:
>> Peter Nilsson <ai...@acay.com.au> wrote:
>> > When in reality, the parentheses have given the contained
>> > "+" a higher precedence than the outer "*".

>> I don't think that's an accurate description.

> In what way is it inaccurate?

Nothing has changed about the precedence of any operators -- parentheses
just turn an arbitrary expression into a primary expression.

>>�It's not horribly wrong,

> How is it wrong in _any_ way, other than not being the way
> you would describe it?

Changing the precedence of an operator would change how it is bound
compared to other operators which are in the same expression, but
parenthesising creates a separate expression.

After that's done, no matter what's in the parentheses, it's treated the
same way an identifier or constant would be -- it's not subject to either
precedence or associativity, it's just become an atom with respect to some
containing expression.

> If you play any trump card games, you can think of it in
> terms that 10 beats 9, which beats 8, which beats 7 etc...
> However, a 9 of hearts may trump a 10 of spades. It's still
> a 9 and it's still lower than a 10, but being a high suit,
> it can sometimes beat a 10 of any lower suit. [Of course,
> the C grammer is not limited to 4 suits of operators. ;-]

I'd say parentheses work, not like a trump, but like moving a hand into a
separate game, in which no other hands may be played.  It wins, not because
it's become a better hand, but because you've removed any possible
competition.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs <usenet-nos...@seebs.net> wrote:
> Peter Nilsson <ai...@acay.com.au> wrote:
> > Seebs <usenet-nos...@seebs.net> wrote:
> > > Peter Nilsson <ai...@acay.com.au> wrote:
> > > > When in reality, the parentheses have given the
> > > > contained "+" a higher precedence than the outer
> > > > "*".
> > >
> > > I don't think that's an accurate description.
> >
> > In what way is it inaccurate?
>
> Nothing has changed about the precedence of any operators

Nothing changes about the relative precedence of operators in
an _unparenthesised_ expression.

>  -- parentheses just turn an arbitrary expression into a
> primary expression.

And parsing that primary expression independantly then
considering it as an atomic operand is isomorphic to
parsing the sub expression as if it had a higher (or
at least separate) tier of precedence to the rest of
the expression.

> > > It's not horribly wrong,
> >
> > How is it wrong in _any_ way, other than not being the way
> > you would describe it?
>
> Changing the precedence of an operator would change how it
> is bound compared to other operators which are in the same
> expression,

But that is *precisely* the purpose of parentheses! To change
the binding of operators. If it weren't necessary to alter the
binding of operators, there would be no need to have
parentheses. But it _is_ necessary to alter the binding of
operators with infix notation.

> but parenthesising creates a separate expression.

It is a sub expression that is part of the original expression.

<snip>
> > If you play any trump card games, you can think of it in
> > terms that 10 beats 9, which beats 8, which beats 7 etc...
> > However, a 9 of hearts may trump a 10 of spades. It's still
> > a 9 and it's still lower than a 10, but being a high suit,
> > it can sometimes beat a 10 of any lower suit. [Of course,
> > the C grammer is not limited to 4 suits of operators. ;-]
>
> I'd say parentheses work, not like a trump, but like moving
> a hand into a separate game, ...

<sigh> Perhaps I can't teach an old dog new tricks. ;)

Consider an analogy of automatic variables in a recursive
function. You're arguing along the lines that they are the
same variables just 'treated separately' with each instance
of the function. Whereas I say they can be viewed as
different variables, with a higher priority of access, even
though they have the same name and come from the same
declaration line.

--
Peter

On 2010-05-14, Peter Nilsson <airia@acay.com.au> wrote:
> Seebs <usenet-nos...@seebs.net> wrote:
>> Peter Nilsson <ai...@acay.com.au> wrote:
>> > Seebs <usenet-nos...@seebs.net> wrote:
>> > > Peter Nilsson <ai...@acay.com.au> wrote:
>> > > > When in reality, the parentheses have given the
>> > > > contained "+" a higher precedence than the outer
>> > > > "*".

>> > > I don't think that's an accurate description.

>> > In what way is it inaccurate?

>> Nothing has changed about the precedence of any operators

> Nothing changes about the relative precedence of operators in
> an _unparenthesised_ expression.

Right.  Operator precedence is fixed.

>>  -- parentheses just turn an arbitrary expression into a
>> primary expression.

> And parsing that primary expression independantly then
> considering it as an atomic operand is isomorphic to
> parsing the sub expression as if it had a higher (or
> at least separate) tier of precedence to the rest of
> the expression.

I think I agree that it has the same effects, but I'm not quite done
thinking that part through.  However, I think there's a significant
conceptual difference between "this changes precedence" and "these
two things are in different expressions, so precedence isn't applicable."

>> Changing the precedence of an operator would change how it
>> is bound compared to other operators which are in the same
>> expression,

> But that is *precisely* the purpose of parentheses! To change
> the binding of operators. If it weren't necessary to alter the
> binding of operators, there would be no need to have
> parentheses. But it _is_ necessary to alter the binding of
> operators with infix notation.

Agreed, but I don't think they do it by modifying precedence.

Imagine that we were to create a syntax for actually modifying precedence;
you could take any operator, and prefix it with a backslash, and that operator
would then have increased precedence, so that:
	
	1 \+ 2 * 3

would be 9.

That would be "modifying precedence".

In
	(1 + 2) * 3
the precedence of + hasn't changed.  It's just that + is in an expression
where there's no higher-precedence operators, and indeed, no other operators
at all.  Similarly, * is now in an expression where it is the only operator;
the operands are both primary expressions, not expressions with operators
in them.

> Consider an analogy of automatic variables in a recursive
> function. You're arguing along the lines that they are the
> same variables just 'treated separately' with each instance
> of the function. Whereas I say they can be viewed as
> different variables, with a higher priority of access, even
> though they have the same name and come from the same
> declaration line.

They're obviously different variables, but I don't think "priority of
access" is the right choice.  It's not just that the local copy is
"higher priority" -- it's the ONLY priority, because the calling function
isn't in scope.

Consider:
	int fact(int x) {
		if (x <= 1)
			return 1;
		return x * fact(x - 1);
	}

If we are to say that the inner x in a call of fact(2) is merely a
higher "priority of access", then what about:

	int fact1(int x) {
		if (x <= 1)
			return 1;
		return x * fact2(x - 1);
	}
	int fact2(int y) {
		if (y <= 1)
			return 1;
		return y * fact1(y - 1);
	}

If it's merely "higher priority of access", then if you call fact1(2),
in the inner call to fact2(1), you should still be able to access x, because
you don't have another x with a higher "priority of access".

But you can't, because it's not priority, but scope, and you've left the
previous scope entirely.

Similarly, when you parenthesize, it's not that the parenthesized expression
has operators with suddenly-higher precedence; it's that it's now a separate
expression entirely.  There's no question of relative precedence; it's not as
though, if you just had a *high enough* precedence, you could beat the
now-increased precedence of the operators in the ().  It's that from the
"(" until you see the ")", you have done something roughly equivalent to
pushing something on a stack; you've entered a new expression, and until
you're done parsing that (as indicated by the closing ")"), you're in a
new context.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 12 May, 14:50, spinoza1111 <spinoza1...@yahoo.com> wrote:

> Operator precedence is in fact defined only for infix expressions in
> the ABSENCE of parentheses, and in ordinary math and compsci, the
> addition and subtraction operators have higher precedence than the
> multiplication and division operators, which was based on praxis in
> high school algebra. Therefore, your statement gives evidence that you
> flunked high school algebra. WTF do you think you are doing at Nokia?

addition and subtraction operators have LOWER precedence than the
multiplication and division operators

Seebs <usenet-nospam@seebs.net> writes:

> On 2010-05-14, Peter Nilsson <airia@acay.com.au> wrote:
<snip>
>> But that is *precisely* the purpose of parentheses! To change
>> the binding of operators. If it weren't necessary to alter the
>> binding of operators, there would be no need to have
>> parentheses. But it _is_ necessary to alter the binding of
>> operators with infix notation.
>
> Agreed, but I don't think they do it by modifying precedence.
>
> Imagine that we were to create a syntax for actually modifying precedence;
> you could take any operator, and prefix it with a backslash, and that operator
> would then have increased precedence, so that:
> 	
> 	1 \+ 2 * 3
>
> would be 9.
>
> That would be "modifying precedence".
>
> In
> 	(1 + 2) * 3
> the precedence of + hasn't changed.

You are happy to postulate a syntax where the \ modifies the precedence
of the operator it is next to, so why do you not want to think of () as
modifying the precedence of the contained operators?  It can't be simply
be the proximity of the symbols that makes one acceptable and the other
alien.

Here's the thing: what is this precedence that you say doesn't change?
C operators have no natural, unchanging, innate precedence -- a parser
may choose to give an operator a precedence and use that to determine
the binding, but this is just one method of parsing an expression.
Another would be parse the grammar in the standard, top down.  The two
results will of course be a close match (but not, I think, an exact
one).  As a result of this duality, people publish operator precedence
tables (K&R included) because we (as humans) find the idea of precedence
and associativity to be a simpler way to think about C expressions.  All
that is being suggested is another way: associate with each operator a
precedence that includes the depth of the nesting it is found in -- and
then ignore the brackets.

[A nice way to think about it to let the ()s collapse down onto the
operators so (1 + 2) * 3 turns into 1 (+) 2 * 3.  The ()s now modify
nothing but the precedence so (+) is just a high priority + operator.
Obviously all ((x)) bind tighter than all (x) which in turn bind more
tightly than the naked x operator.]

Why do this?  Well, it may help some people understand precedence and
parentheses -- it's always good to have lots of alternate ways of
thinking about things.

And it can't hurt to have other ways to code expression parsing.  In
that spirit (and because there has not been enough code to pick at
recently) here is a version of Dijkstra's classic shunting yard
algorithm that just counts brackets rather than pushing and popping
them.  I am not claiming there is much practical benefit to doing it
this way (the logic of the code is a little simpler but the information
on the stack is a little more complex) -- I just think there's always
room for other ways to do things.

A few notes about this method: by being relaxed about checking it will
parse the version where the brackets are only round the operator.  Thus
"1 (+) 2 * 3" is parsed as "(1 + 2) * 3".  Also, by treating the
precedence as signed, I decided to permit "anti-parentheses" which lower
the binding.  Thus we could also write the previous expression as "1 +
)2 * 3(" or by even as "1 + 2 )*( 3".  I.e. ")*(" is just a low priority
multiplication operator.

<snip>

#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>
#include <limits.h>
#include <ctype.h>

struct operator {
     int token;
     int precedence;
};

bool            stack_empty(void);
void            stack_push(struct operator op);
struct operator stack_pop(void);
struct operator stack_top(void);

int get_token(FILE *f);


void shunt_exp(FILE *in, FILE *out)
{
     int precedence[UCHAR_MAX] = {
          ['*'] = 3, ['/'] = 3, ['%'] = 3,
          ['+'] = 2, ['-'] = 2,
          ['='] = 1,
      };

     int token, nesting = 0;
     while ((token = get_token(in)) != EOF)
          if (isalnum(token))
               fputc(token, out);
          else if (token == '(')
               ++nesting;
          else if (token == ')') {
                    --nesting;
          }
          else {
               struct operator op = {
                    token,
                    precedence[token] + 100*nesting
               };
               while (!stack_empty() &&
                      op.precedence <= stack_top().precedence)
                    fputc(stack_pop().token, out);
               stack_push(op);
          }
     if (nesting != 0)
          fprintf(stderr, "Too many %cs.\n", nesting > 0 ? '(' : ')');
     while (!stack_empty())
          fputc(stack_pop().token, out);
}

int main(void)
{
     shunt_exp(stdin, stdout);
     return 0;
}


/* Here is just enough of a stack and an input function get things going. */

#define STACK_SIZE 10

static struct operator stack[STACK_SIZE];
static size_t top_of_stack = 0;

bool stack_empty(void)
{
     return top_of_stack == 0;
}

void stack_push(struct operator op)
{
     if (top_of_stack >= STACK_SIZE) {
          fprintf(stderr, "Stack overflow.\n");
          exit(EXIT_FAILURE);
     }
     else stack[top_of_stack++] = op;
}

struct operator stack_pop(void)
{
     if (stack_empty()) {
          fprintf(stderr, "Stack underflow.\n");
          exit(EXIT_FAILURE);
     }
     else return stack[--top_of_stack];
}

struct operator stack_top(void)
{
     return stack[top_of_stack - 1];
}

int get_token(FILE *f)
{
     int c;
     while (isspace(c = fgetc(f)));
     return c;
}

-- 
Ben.

On 2010-05-15, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> You are happy to postulate a syntax where the \ modifies the precedence
> of the operator it is next to, so why do you not want to think of () as
> modifying the precedence of the contained operators?  It can't be simply
> be the proximity of the symbols that makes one acceptable and the other
> alien.

I guess for the same reason that I don't view ; as increasing the precedence
of operators.  That's not how it works.

> Another would be parse the grammar in the standard, top down.  The two
> results will of course be a close match (but not, I think, an exact
> one).  As a result of this duality, people publish operator precedence
> tables (K&R included) because we (as humans) find the idea of precedence
> and associativity to be a simpler way to think about C expressions.  All
> that is being suggested is another way: associate with each operator a
> precedence that includes the depth of the nesting it is found in -- and
> then ignore the brackets.

Ohhhhhh.

> Why do this?  Well, it may help some people understand precedence and
> parentheses -- it's always good to have lots of alternate ways of
> thinking about things.

I guess.  I think the thing is...

1.  While it is another way to think about things, it seems to me that it's
a simile, not a description.  It is, I think, true that parentheses have an
effect similar to what you'd get if you could increase the precedence of
operators, but that's not how they're defined and I don't think it's how
anything actually parses it.
2.  It sounds to me to be a much more complex way to think about things.
To me, "() makes a separate sub-expression, and is then an atom in
the containing expression" is super obvious, but "and then these things
all have their precedence increased, relatively, but are still part of the
same expression".  Which gives the impression that if you could just
figure out how to write it, you'd be able to get a (x+y) and a (w*z) to
interact such that the *'s still-higher precedence would win.  (You
can't, of course, because they need one of the other operators between
them...)

Hmm.  I guess a lot of this is probably just that, while I'm fine with
ways-of-thinking, I get fussy if someone says that the way of thinking
is really what happens.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs <usenet-nospam@seebs.net> writes:

> On 2010-05-15, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> You are happy to postulate a syntax where the \ modifies the precedence
>> of the operator it is next to, so why do you not want to think of () as
>> modifying the precedence of the contained operators?  It can't be simply
>> be the proximity of the symbols that makes one acceptable and the other
>> alien.
>
> I guess for the same reason that I don't view ; as increasing the precedence
> of operators.  That's not how it works.

That seems circular.  You don't like to think of it that way because "it
does not work like that" is an odd reply to a post about how it can be
made to work that way.

>> Another would be parse the grammar in the standard, top down.  The two
>> results will of course be a close match (but not, I think, an exact
>> one).  As a result of this duality, people publish operator precedence
>> tables (K&R included) because we (as humans) find the idea of precedence
>> and associativity to be a simpler way to think about C expressions.  All
>> that is being suggested is another way: associate with each operator a
>> precedence that includes the depth of the nesting it is found in -- and
>> then ignore the brackets.
>
> Ohhhhhh.
>
>> Why do this?  Well, it may help some people understand precedence and
>> parentheses -- it's always good to have lots of alternate ways of
>> thinking about things.
>
> I guess.  I think the thing is...
>
> 1.  While it is another way to think about things, it seems to me that it's
> a simile, not a description.

I don't get this distinction.  All the different ways of thinking about
the (syntactic) meaning of expressions seem to me to be at the same
level -- they explain how a strings map to a parse trees.  What do you
mean when you say one way is a simile and another a description.

I would concede that one method is privileged: the grammar in the
language standard is the *definition* of this mapping and all other
explanations (like operator precedence) would have to be shown to be
similar (or at least sufficiently similar).

>  It is, I think, true that parentheses have an
> effect similar to what you'd get if you could increase the precedence of
> operators, but that's not how they're defined and I don't think it's how
> anything actually parses it.

Do you think about C operators using precedence and associativity?  They
are not defined like, that but most people prefer the resulting
approximation to the full grammar.  I'd be quite happy if you just said
you don't like it, but objecting because ()s are not defined like that
is only fair if you object to all operator precedence views of C's
expressions.

As for anything doing it that way, I don't know and I certainly don't
want to argue about it.  I am not sure it matters when talking about
alternate ways of thinking about expressions.

> 2.  It sounds to me to be a much more complex way to think about things.
> To me, "() makes a separate sub-expression, and is then an atom in
> the containing expression" is super obvious, but "and then these things
> all have their precedence increased, relatively, but are still part of the
> same expression".

Your paraphrase is not fair!  Anyway, it may well be more complex.  I
would not want to sell it on the grounds of simplicity.

>  Which gives the impression that if you could just
> figure out how to write it, you'd be able to get a (x+y) and a (w*z) to
> interact such that the *'s still-higher precedence would win.  (You
> can't, of course, because they need one of the other operators between
> them...)
>
> Hmm.  I guess a lot of this is probably just that, while I'm fine with
> ways-of-thinking, I get fussy if someone says that the way of thinking
> is really what happens.

I feel the same, but I thought that what really happens was a the very
heart of your very argument: "that's not how it works" you said at the
start and later: "I don't think it's how anything actually parses it".

-- 
Ben.

On 2010-05-15, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> I guess for the same reason that I don't view ; as increasing the precedence
>> of operators.  That's not how it works.

> That seems circular.  You don't like to think of it that way because "it
> does not work like that" is an odd reply to a post about how it can be
> made to work that way.

I was responding more to the "way of thinking about it" aspect.  I grant
that it could actually probably be done equivalently, but it's not what
the language spec describes, nor do I know of a parser which works that
way.

>> 1.  While it is another way to think about things, it seems to me that it's
>> a simile, not a description.

> I don't get this distinction.  All the different ways of thinking about
> the (syntactic) meaning of expressions seem to me to be at the same
> level -- they explain how a strings map to a parse trees.  What do you
> mean when you say one way is a simile and another a description.

I mean that if you actually look at the data structures inside any compiler
I've yet seen, it is not using a table of precedence and then increasing
the precedence of the operators inside the ().

> Do you think about C operators using precedence and associativity?

Not usually -- I find the type-of-expression thing (primary expression,
additive expression, etc.) much clearer.

> They
> are not defined like, that but most people prefer the resulting
> approximation to the full grammar.  I'd be quite happy if you just said
> you don't like it, but objecting because ()s are not defined like that
> is only fair if you object to all operator precedence views of C's
> expressions.

I don't entirely agree.  The equivalence of the expression-naming thing
to precedence is clear, but when you do that and build a precedence table,
it doesn't have multiple copies of everything, with each set marked as
"inside another set of ()".

> As for anything doing it that way, I don't know and I certainly don't
> want to argue about it.  I am not sure it matters when talking about
> alternate ways of thinking about expressions.

A way of thinking about something that describes its behavior, but not
its mechanism, is good as a way-of-thinking-about, but not good as a
description of what actually happens.

> Your paraphrase is not fair!

Sorry.  I don't really *get* the precedence description, I don't think.

>> Hmm.  I guess a lot of this is probably just that, while I'm fine with
>> ways-of-thinking, I get fussy if someone says that the way of thinking
>> is really what happens.

> I feel the same, but I thought that what really happens was a the very
> heart of your very argument: "that's not how it works" you said at the
> start and later: "I don't think it's how anything actually parses it".

Yes.  So if someone said "one way to think about parentheses is as if they
increased the precedence of all operators inside them so that relative
precedence is preserved within the parentheses, but everything inside them
has higher precedence than anything outside them", I wouldn't complain.
But if someone said "what parentheses do is increase the precedence of...",
I'd complain, because that's not what they do -- it's just a way of thinking
about what they do.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs wrote:
) I mean that if you actually look at the data structures inside any compiler
) I've yet seen, it is not using a table of precedence and then increasing
) the precedence of the operators inside the ().

How many compilers have you seen that use a table of precedence, period ?

What I've seen most often is a grammar graph with the most-tightly
binding operator at the root, going down from there, but with parens
making it point back to the root again.  That makes it a loop, and
more parens means going round the loop more times.

The precedence is implicit in how many steps from the start you are,
and parens make you go round the loop more, so parens increase the
precedence.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

On 2010-05-15, Willem <willem@turtle.stack.nl> wrote:
> How many compilers have you seen that use a table of precedence, period ?

None outside of example programs.

This is why I don't think describing parentheses as "increasing precedence"
is accurate.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs wrote:
) On 2010-05-15, Willem <willem@turtle.stack.nl> wrote:
)> How many compilers have you seen that use a table of precedence, period ?
)
) None outside of example programs.
)
) This is why I don't think describing parentheses as "increasing precedence"
) is accurate.

So you also don't think that describing multiplication
as having greater precedence than addition is accurate ?


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

On 2010-05-15, Willem <willem@turtle.stack.nl> wrote:
> Seebs wrote:
> ) This is why I don't think describing parentheses as "increasing precedence"
> ) is accurate.

> So you also don't think that describing multiplication
> as having greater precedence than addition is accurate ?

....

Huh.  Weird -- that is definitely an inconsistency in my mental map of
this.

I'm still not sure why it just seems so clearly wrong to me to describe ()s
in terms of precedence rather than in terms of a separate expression.

Hmm.  Thinking about it, I think it's just the (...) matching -- you
couldn't possibly split a () around anything else without ending up with
mismatched ()s, so obviously they're self-contained, and thus precedence
isn't at issue.

With something like
	a + b * c + d
you COULD split the expression in any of several places -- using "precedence"
to describe how you decide helps, but it doesn't matter; the expression
wouldn't be *incoherent* if you just swapped the precedence around, it'd
just change its value.

But with
	a + (b * c) + d
it would make no sense at all to split this into
	a + (b
	*
	c) + d

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs <usenet-nospam@seebs.net> writes:

> On 2010-05-15, Willem <willem@turtle.stack.nl> wrote:
>> How many compilers have you seen that use a table of precedence, period ?
>
> None outside of example programs.

gcc does unless Willem's question was trap.  It uses a switch to map
operators to precedence values (rather than an array) but I still call
that a "table of precedence".

> This is why I don't think describing parentheses as "increasing precedence"
> is accurate.

"Not accurate" is a very strong criticism of the idea but for the sanity
of the group it's probably best to let this pass.  There does not seem
to be much to be gained from going round the loop again.

-- 
Ben.

On 2010-05-15, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> On 2010-05-15, Willem <willem@turtle.stack.nl> wrote:
>>> How many compilers have you seen that use a table of precedence, period ?

>> None outside of example programs.

> gcc does unless Willem's question was trap.  It uses a switch to map
> operators to precedence values (rather than an array) but I still call
> that a "table of precedence".

Well, shows what I know -- I haven't looked that closely at gcc's source.
(Or at least that part of it.)

But this raises an interesting question:  Given that it does, in fact,
map operators to precedence values, does it then implement parentheses by
increasing the precedence of operators?  If so, I would be obliged to concede
that the description is in fact accurate.  If not, then we have a clear
example of something which really does use precedence, but in which
parentheses do not result in higher precedence.

Looking at it, it looks to be done in YACC, and what it does is:

        '(' expr ')'

which is to say, it parses a sub-expression between ( and ), and does not
change the parsing of that expression in any way -- nothing has its precedence
changed, everything continues to have the same precedence.

That fits my expectation of how it would be done.  You can't split a (...)
up partway through, so "precedence" is not a good explanation of why
operators inside () are treated like an atom from the point of view of
the containing expression.  It's just that (...) is a primary expression,
like an identifier or a constant.

> "Not accurate" is a very strong criticism of the idea but for the sanity
> of the group it's probably best to let this pass.  There does not seem
> to be much to be gained from going round the loop again.

At least it's more *topical* than the usual run of pointless arguments.  :)

I'm actually being fascinated by this.  At this point, I'd say it's pretty
clear that my way of thinking about C expressions is not particularly typical
among the posters here, which leads me to suspect that I should perhaps
think about revising that criticism.  I'd been under the impression that
most people who had a good grasp of C would view (...) as a primary
expression, and the question of "precedence" between that and other things
it was in an expression with as irrelevant.  Apparently this is not so.

Okay, next question:

	foo(1 + 2) * bar(2 + 3)

is the function call "operator" (using the term loosely) raising the
precedence of +, or are the function arguments separate expressions which
don't even participate in a comparison of precedence with the *?

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs <usenet-nospam@seebs.net> writes:
<snip>
> Hmm.  Thinking about it, I think it's just the (...) matching -- you
> couldn't possibly split a () around anything else without ending up with
> mismatched ()s, so obviously they're self-contained, and thus precedence
> isn't at issue.

I am often worried by things that are obvious.  It is certainly the way
we learn to view ()s but *must* they be treated as indivisible units?  I
give an example below of how they might not be.

> With something like
> 	a + b * c + d
> you COULD split the expression in any of several places -- using "precedence"
> to describe how you decide helps, but it doesn't matter; the expression
> wouldn't be *incoherent* if you just swapped the precedence around, it'd
> just change its value.

Right.

> But with
> 	a + (b * c) + d
> it would make no sense at all to split this into
> 	a + (b
> 	*
> 	c) + d

Who's suggesting that?  This expression has one parse regardless of
which view of parentheses we take.

But there is no mathematical rule that says that expressions must be as
limited as the ones we've grown up with.  If you take a deep breath and
embrace the idea that ()s are just about precedence and not about
indivisible units one can image expressions like:

  a ((+)) (b * c) ((+)) d

Here the outer ((+)) operators are so "strong" they pull apart the inner
(b * c) expression.  Using the parser I posted:

  $ ./shunt <<< "a ((+)) (b * c) ((+)) d"
  ab+cd+*

and this is not the oddest kind of expression one can imagine.

I am not suggesting such monstrosities be added to C, but it does
illustrate how changing perspective can open up new possibilities.
every now and then these new possibilities do turn out to be useful.

-- 
Ben.

Seebs wrote:
) I'm actually being fascinated by this.  At this point, I'd say it's pretty
) clear that my way of thinking about C expressions is not particularly typical
) among the posters here, which leads me to suspect that I should perhaps
) think about revising that criticism.  I'd been under the impression that
) most people who had a good grasp of C would view (...) as a primary
) expression, and the question of "precedence" between that and other things
) it was in an expression with as irrelevant.  Apparently this is not so.

Perhaps you should entertain the possibility that most people see (...) as
a primary expression, just like you do, but are also able to shift their
view and see it as increasing precedence.

You're arguing that 'parentheses increase precedence' is *necessarily*
wrong.  Those arguing against you think it has validity as a viewpoint,
not that it is the One True Way.

) Okay, next question:
)
) 	foo(1 + 2) * bar(2 + 3)
)
) is the function call "operator" (using the term loosely) raising the
) precedence of +, or are the function arguments separate expressions which
) don't even participate in a comparison of precedence with the *?

Both.

Although it's more of a mental leap to see it as increasing precedence:

If you view foo(argument) as equivalent
to 'foo <apply> (argument)', then that becomes:

foo <apply> (1 + 2) * bar <apply> (2 + 3)

And you're back to the previous way of thinking.

NB: the <apply> operator has the highest precedence in this case.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

On 2010-05-16, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> With something like
>> 	a + b * c + d
>> you COULD split the expression in any of several places -- using "precedence"
>> to describe how you decide helps, but it doesn't matter; the expression
>> wouldn't be *incoherent* if you just swapped the precedence around, it'd
>> just change its value.

> Right.

>> But with
>> 	a + (b * c) + d
>> it would make no sense at all to split this into
>> 	a + (b
>> 	*
>> 	c) + d

> Who's suggesting that?  This expression has one parse regardless of
> which view of parentheses we take.

But precedence is how you determine the binding of operators -- meaning it
is only conceptually relevant when there is a choice of bindings available.

> I am not suggesting such monstrosities be added to C, but it does
> illustrate how changing perspective can open up new possibilities.
> every now and then these new possibilities do turn out to be useful.

Interesting.  So, imagining that we had the () around an operator increase
its precedence... Okay, so imagine that:

	a (+) b * c
is the same as (existing notation)
	(a + b) * c

What, then, happens with:
	a (+) b (*) c
?

It seems that's equivalent to
	a + (b * c)
but I'm not sure how you'd model it; you have to sort of push the ()s out,
but you have to do it to higher-precedence operators first.  Or really model
it as a whole new tier of precedence...

I dunno.  This just seems more complicated to me.  I am fine with granting
that thinking about () in terms of precedence is interesting, I just don't
think it seems like a good description of what happens.  I'm still not quite
sure whether I think it's wrong or just a confusing but apparently equivalent
explanation.  It's in the same category, to me, as talking about "the stack";
it can be a good way to explain things, offered as a way of thinking about
things, with the understanding that this is not necessarily the underlying
mechanism.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 2010-05-16, Willem <willem@turtle.stack.nl> wrote:
> Perhaps you should entertain the possibility that most people see (...) as
> a primary expression, just like you do, but are also able to shift their
> view and see it as increasing precedence.

Huh.  That's a possibility, I guess.  I haven't been able to make sense
of the "increasing precedence" model yet -- I mean, I can do the paperwork
to show that it appears to yield equivalent results, but it doesn't look
like a thing which would happen to me.

I can do the math to show that viewing the solar system as revolving around
the earth, with planets doing epicycles, is a consistent model and produces
the same results as the heliocentric model, but it doesn't seem to me to be
a good model, even if it produces the same results, because it doesn't seem
that it's a good description of what really happens.

> You're arguing that 'parentheses increase precedence' is *necessarily*
> wrong.  Those arguing against you think it has validity as a viewpoint,
> not that it is the One True Way.

Fair enough.

> ) Okay, next question:
> )
> ) 	foo(1 + 2) * bar(2 + 3)
> )
> ) is the function call "operator" (using the term loosely) raising the
> ) precedence of +, or are the function arguments separate expressions which
> ) don't even participate in a comparison of precedence with the *?

> Both.

Hmm.  Interesting.

> Although it's more of a mental leap to see it as increasing precedence:

> If you view foo(argument) as equivalent
> to 'foo <apply> (argument)', then that becomes:

> foo <apply> (1 + 2) * bar <apply> (2 + 3)

> And you're back to the previous way of thinking.

True.  It gets weirder if you add multi-argument functions, though,
because those aren't the same commas that are in the comma operator...

Actually, there I have an actual concrete distinction to draw:  Parentheses
really do something that is NOT the same as increasing precedence.

	printf("%d\n", (1, 2));

that's not "increasing the precedence" of the comma operator -- without the
(), there ISN'T a comma operator.

So they are doing something that's actually different from just increasing
precedence, and which I can't figure out a way to express within the
increasing-precedence description.  They introduce a whole new, separate,
expression context, and until the matching ), nothing can break that
expression, not because of precedence, but because it's a separate parse
of "an expression", and the components of that sub-expression simply aren't
participating in the context of the surrounding expression.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs <usenet-nospam@seebs.net> writes:

> On 2010-05-15, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Seebs <usenet-nospam@seebs.net> writes:
>>> On 2010-05-15, Willem <willem@turtle.stack.nl> wrote:
>>>> How many compilers have you seen that use a table of precedence, period ?
>
>>> None outside of example programs.
>
>> gcc does unless Willem's question was trap.  It uses a switch to map
>> operators to precedence values (rather than an array) but I still call
>> that a "table of precedence".
>
> Well, shows what I know -- I haven't looked that closely at gcc's source.
> (Or at least that part of it.)
>
> But this raises an interesting question:  Given that it does, in fact,
> map operators to precedence values, does it then implement parentheses by
> increasing the precedence of operators?

Gcc does not do this.  I would not have kept that back if it did!

>  If so, I would be obliged to concede
> that the description is in fact accurate.  If not, then we have a clear
> example of something which really does use precedence, but in which
> parentheses do not result in higher precedence.

One among many I would guess.  I don't think anyone is arguing that this
idea is common place or widely used in practise; merely that it is an
interesting way to think about expressions.

> Looking at it, it looks to be done in YACC, and what it does is:
>
>         '(' expr ')'
>
> which is to say, it parses a sub-expression between ( and ), and does not
> change the parsing of that expression in any way -- nothing has its precedence
> changed, everything continues to have the same precedence.

The source I looked at[1] does not use YACC -- it had a hand-rolled parser.
It seems to be the main trunk (modified a few hours ago) but my CVS foo
is weak.

> That fits my expectation of how it would be done.  You can't split a (...)
> up partway through, so "precedence" is not a good explanation of why
> operators inside () are treated like an atom from the point of view of
> the containing expression.  It's just that (...) is a primary expression,
> like an identifier or a constant.

This seems rather circular.  Any explanation of parentheses that does
not treat ()s as making an atom is bound to seem like a bad explanation
of why ()s behave like an atom.

But I can see why you are worried.  In another post I explain how this
idea of atomic sub-expressions is not set in stone: (...) can be split
apart by surrounding operators, though it needs a more general
expression syntax than is commonly used.  It takes some reasoning to be
sure that the usual syntax holds no surprises when interpreted using
alternative view of parentheses.

<snip>
Willem has commented on your last two points in exactly the way I
would have liked to had I his facility with words.

[1] http://gcc.gnu.org/viewcvs/trunk/gcc/c-parser.c?revision=159442&view=markup
-- 
Ben.

Seebs <usenet-nospam@seebs.net> writes:

> On 2010-05-16, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Seebs <usenet-nospam@seebs.net> writes:
>>> With something like
>>> 	a + b * c + d
>>> you COULD split the expression in any of several places -- using "precedence"
>>> to describe how you decide helps, but it doesn't matter; the expression
>>> wouldn't be *incoherent* if you just swapped the precedence around, it'd
>>> just change its value.
>
>> Right.
>
>>> But with
>>> 	a + (b * c) + d
>>> it would make no sense at all to split this into
>>> 	a + (b
>>> 	*
>>> 	c) + d
>
>> Who's suggesting that?  This expression has one parse regardless of
>> which view of parentheses we take.
>
> But precedence is how you determine the binding of operators -- meaning it
> is only conceptually relevant when there is a choice of bindings
> available.

Sorry, I don't follow this.

[Big unmarked snip here.  Without the example the following reads oddly.]

>> I am not suggesting such monstrosities be added to C, but it does
>> illustrate how changing perspective can open up new possibilities.
>> every now and then these new possibilities do turn out to be useful.
>
> Interesting.  So, imagining that we had the () around an operator increase
> its precedence... Okay, so imagine that:
>
> 	a (+) b * c
> is the same as (existing notation)
> 	(a + b) * c

Yes.  I gave some other examples in the post where I posted a parser.

> What, then, happens with:
> 	a (+) b (*) c
> ?
>
> It seems that's equivalent to
> 	a + (b * c)

Yup.  Other interesting example might be 

      a (+ b) * c
and
      a + b )*( c

> but I'm not sure how you'd model it; you have to sort of push the ()s out,
> but you have to do it to higher-precedence operators first.  Or really model
> it as a whole new tier of precedence...

It's a whole new tier.  There are all sorts of ways to model this.  One
way is to attach to each operator the nesting level and the (normal)
precedence as a pair (n, p) and use this pair as the actual precedence
for the purposes of parsing: the comparison being lexicographical.  My
little parser just formed n*100 + p because p was always < 100.

E.g. in 'a (+) b * c' the operators have precedence (1, 1) and (0, 2).
In 'a + b )*( c' they are (0, 1) and (-1, 2).

> I dunno.  This just seems more complicated to me.  I am fine with granting
> that thinking about () in terms of precedence is interesting, I just don't
> think it seems like a good description of what happens.

What does happen?  If the parser uses YACC, the description of "what
happens" takes many pages.  If the parse uses another mechanism,
something else happens.  I don't think there is one privileged view
of expressions backed up by "what happens".

>  I'm still not quite
> sure whether I think it's wrong or just a confusing but apparently equivalent
> explanation.  It's in the same category, to me, as talking about "the stack";
> it can be a good way to explain things, offered as a way of thinking about
> things, with the understanding that this is not necessarily the underlying
> mechanism.

I have no argument with that despite disagreeing (for example I don't
find it either wrong or confusing).

-- 
Ben.

Seebs <usenet-nospam@seebs.net> writes:
<snip>
> True.  It gets weirder if you add multi-argument functions, though,
> because those aren't the same commas that are in the comma operator...
>
> Actually, there I have an actual concrete distinction to draw:  Parentheses
> really do something that is NOT the same as increasing precedence.
>
> 	printf("%d\n", (1, 2));
>
> that's not "increasing the precedence" of the comma operator -- without the
> (), there ISN'T a comma operator.

You've extended the claim.  No one has said that parentheses *only*
increase the precedence of enclosed operators.  They can also alter the
parse of an argument list -- making an expression where there would
otherwise be two arguments.

Imagine your reaction if I cited printf("%d\n", 1, 2) as a counter
example to your view that (...) turns the contents into a primary
expression.  Some brackets do, but not all.

<snip>
-- 
Ben.

On 2010-05-16, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> But precedence is how you determine the binding of operators -- meaning it
>> is only conceptually relevant when there is a choice of bindings
>> available.

> Sorry, I don't follow this.

Okay, consider:
	a + b;
	c * d;
Precedence has no involvement in how we determine the values of these two
expressions, because there's no possible choice-of-bindings.  Each expression
is self-contained.

But in:
	a + b * c;
we see that precedence *does* matter, because it's a way of explaining how
we resolve ambiguity.

In
	(a + b) * c;
there is no precedence at issue; there is no ambiguity about how the operators
would bind, and no point at which you have a choice of which of two operators
to handle.

> [Big unmarked snip here.  Without the example the following reads oddly.]

Sorry, bad habit -- I tend to snip to enough context that you can see
what was going on if you read the previous post, probably.

>> I dunno.  This just seems more complicated to me.  I am fine with granting
>> that thinking about () in terms of precedence is interesting, I just don't
>> think it seems like a good description of what happens.

> What does happen?  If the parser uses YACC, the description of "what
> happens" takes many pages.  If the parse uses another mechanism,
> something else happens.  I don't think there is one privileged view
> of expressions backed up by "what happens".

I don't think it takes many pages.  What happens is the parser looks
for an "expr" and a following ).  That's it; it starts a whole new
expression-parser, and the whole expression thus parsed becomes the
value of the atom.

> I have no argument with that despite disagreeing (for example I don't
> find it either wrong or confusing).

I'm suspecting that, if I weren't confused by it, I might no longer think
it was wrong, but I've been unable to get it to map correctly onto how C
expressions work yet.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 2010-05-16, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> You've extended the claim.  No one has said that parentheses *only*
> increase the precedence of enclosed operators.  They can also alter the
> parse of an argument list -- making an expression where there would
> otherwise be two arguments.

Ah-hah!

I think that may be where the divergence happened.

I understood the claim in question to be a *definition* of parentheses,
not merely a statement about their effect.

> Imagine your reaction if I cited printf("%d\n", 1, 2) as a counter
> example to your view that (...) turns the contents into a primary
> expression.  Some brackets do, but not all.

Ahh, I see.  I view fn() as different ()s than (expr).  I'm just looking
at () as the thing which (in one way of describing it) groups expressions.
I understood Schildt to be offering a *definition* of (), that it "increases
the precedence of operators".  But that definition doesn't explain what
()s do in a context like function argument lists.

I feel somewhat justified in that interpretation.  That sentence is the
ENTIRETY of the explanation given.  We see (4e, page 57):

	The [ ] and ( ) Operators
		Parentheses are operators that increase the precedence
		of the operations inside them.  Square brackets perform
		array indexing [...]

There is no further reference to parentheses in this section.
The next reference I see is (4e, page 61):

	Spacing and Parentheses

		You can add tabs and spaces to expressions to make them
		easier to read.  For example, the following two expressions
		are the same:
			x=10/y~(127/x);
			x = 10 / y ~(127/x);
		Redundant or additional parentheses do not cause errors
		or slow down the execution of an expression.  You should
		use parentheses to clarify the exact order of evaluation,
		both for yourself and for others.  For example, which of
		the following two expressions is easier to read?
			x = y/3-34*temp+127;
			x = (y/3) - (34*tmp) + 127;

Note:  Yes, I'm aware that the first example is uncompileable.  I'm
guessing that the ~ was supposed to be a minus sign, but the spacing
suggests that, by the time it was revised, it was clearly understood to be
a tilde, because it's spaced as a unary operator rather than a binary.

Given this, it really seems as though the intent is to offer that explanation
as the complete and exhaustive definition of (), at which point I do feel
comfortable stating that it's wrong.

The term "parenthesis" (or parentheses) does not occur in the index.  I
can't find anything which indicates, explains, or suggests that there
is any significance to parentheses other than influencing order of
evaluation.  (And note that he does say "order of evaluation" here.)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs <usenet-nospam@seebs.net> writes:

> On 2010-05-16, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> You've extended the claim.  No one has said that parentheses *only*
>> increase the precedence of enclosed operators.  They can also alter the
>> parse of an argument list -- making an expression where there would
>> otherwise be two arguments.
>
> Ah-hah!
>
> I think that may be where the divergence happened.
>
> I understood the claim in question to be a *definition* of parentheses,
> not merely a statement about their effect.

Indeed not.  How could it be?  Parentheses are used for all sorts of
quite different purposes in C: function calls, parameter lists, casts,
compound literals, declarators... even in some statements.  All these
can be thought of "other syntax" with nothing to do with grouping in an
expression.

The "merely a statement about their effect" is polemic!  For the
grouping parentheses used in expressions, the claim describes their
effect sufficiently well to be used as a definition.  I accept it is not
how they are defined, but it could be.

Reading on, I see that you are still concerned about Schildt's
perfunctory definition of brackets.  It has not been my intention to
defend it.  If one were to define the meaning of grouping parentheses
this way, one would have to say a whole lot more than Schildt does, and
the effect would be unnecessarily complex.

>> Imagine your reaction if I cited printf("%d\n", 1, 2) as a counter
>> example to your view that (...) turns the contents into a primary
>> expression.  Some brackets do, but not all.
>
> Ahh, I see.  I view fn() as different ()s than (expr).  I'm just looking
> at () as the thing which (in one way of describing it) groups
> expressions.

Yes, so was I.

> I understood Schildt to be offering a *definition* of (), that it "increases
> the precedence of operators".  But that definition doesn't explain what
> ()s do in a context like function argument lists.

Ah, here is where I see my area of divergence.  I was not commenting on
Schildt's statement.

My point was simply that there is another way to look at ()s and that it
is (a) adequate to explain how C's "grouping parentheses" and (b) it is
interesting in its own right in that it permits one to imagine new
expression forms that are normally discounted.

> I feel somewhat justified in that interpretation.  That sentence is the
> ENTIRETY of the explanation given.  We see (4e, page 57):
>
> 	The [ ] and ( ) Operators
> 		Parentheses are operators that increase the precedence
> 		of the operations inside them.  Square brackets perform
> 		array indexing [...]

Yuck.  I would not describe () as an operator except in the context of
function calls and it does not seem to be those ()s that he is talking
about.

I would never advocate using the notion I've been defending as a way to
explain C's "grouping parentheses" in C book.  I was simply defending it
against an apparent wholesale rejection of the notion.

> There is no further reference to parentheses in this section.
> The next reference I see is (4e, page 61):
>
> 	Spacing and Parentheses
>
> 		You can add tabs and spaces to expressions to make them
> 		easier to read.  For example, the following two expressions
> 		are the same:
> 			x=10/y~(127/x);
> 			x = 10 / y ~(127/x);
> 		Redundant or additional parentheses do not cause errors
> 		or slow down the execution of an expression.  You should
> 		use parentheses to clarify the exact order of
> 		evaluation,

[Oh dear]

> 		both for yourself and for others.  For example, which of
> 		the following two expressions is easier to read?
> 			x = y/3-34*temp+127;
> 			x = (y/3) - (34*tmp) + 127;
>
> Note:  Yes, I'm aware that the first example is uncompileable.  I'm
> guessing that the ~ was supposed to be a minus sign, but the spacing
> suggests that, by the time it was revised, it was clearly understood to be
> a tilde, because it's spaced as a unary operator rather than a binary.
>
> Given this, it really seems as though the intent is to offer that explanation
> as the complete and exhaustive definition of (), at which point I do feel
> comfortable stating that it's wrong.

When you have said "this is wrong" or "this is confusing" I thought you
were talking about something I'd said.  Clearly, the above is confusing
and obviously wrong in many respects, but there is a germ of truth in
the statement about ()s and precedence.

> The term "parenthesis" (or parentheses) does not occur in the index.  I
> can't find anything which indicates, explains, or suggests that there
> is any significance to parentheses other than influencing order of
> evaluation.  (And note that he does say "order of evaluation" here.)

Yes, I saw that.

I had forgotten that this all started because of a statement in C:TCR.
That might explain the strength of your opposition to what I thought of
as an uncontentious observation: that ()s can be seen as syntax whose
role is to alter the precedence relationship between operators rather
than as syntax to group sub-expressions.  I saw this exchange as
off-topic because I was not talking about any application of the idea to
understanding or parsing C expressions (specifically) whereas I think
you may have been thinking of it as an extended commentary on Schildt's
remark.

-- 
Ben.

Seebs <usenet-nospam@seebs.net> writes:

> On 2010-05-16, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Seebs <usenet-nospam@seebs.net> writes:
>>> But precedence is how you determine the binding of operators -- meaning it
>>> is only conceptually relevant when there is a choice of bindings
>>> available.
>
>> Sorry, I don't follow this.
>
> Okay, consider:
> 	a + b;
> 	c * d;
> Precedence has no involvement in how we determine the values of these two
> expressions, because there's no possible choice-of-bindings.  Each expression
> is self-contained.
>
> But in:
> 	a + b * c;
> we see that precedence *does* matter, because it's a way of explaining how
> we resolve ambiguity.
>
> In
> 	(a + b) * c;
> there is no precedence at issue; there is no ambiguity about how the operators
> would bind, and no point at which you have a choice of which of two operators
> to handle.

OK, I see what you mean.  In all sane interpretations of what can be a
valid expression, I agree.  But also like to consider insane
interpretations, and there is an entirely logical view of what an
expression means in which a operator can have binding so strong it
breaks into neighbouring parentheses.  Hence my example of

  (a + b) ((*)) c.

<snip>
>>> I dunno.  This just seems more complicated to me.  I am fine with granting
>>> that thinking about () in terms of precedence is interesting, I just don't
>>> think it seems like a good description of what happens.

I don't think I explained myself very well here so I'll snip and address
this point again.

I was not suggesting it was a good description of what happens.  But what
happens during a parse is not obviously the best way to explain
something like ()s.  And if a parser did it this peculiar way, that
would not necessarily be a reason to use it as an explanation.  In other
words I am not keen on an appeal to "what happens" either way.

I am fine with granting that it's not the first explanation I'd reach
for.  I might use it as an alternative if someone seemed to be having
trouble, but that's unlikely.  Almost everyone will be so familiar with
()s from basic arithmetic that the only explanation needed will be one
about binding vs. order of evaluation so as to unlearn the idea that
higher precedence operators and grouped expressions "happen first".

<snip>
> I'm suspecting that, if I weren't confused by it, I might no longer think
> it was wrong, but I've been unable to get it to map correctly onto how C
> expressions work yet.

Would your last sentence still be true if you deleted the words "how"
and "work"?  In other words, is your problem with it primarily due to
what you know about how one or more C compilers parse expression, or it
with the meaning it gives to expressions independently of how they are
parsed?

-- 
Ben.

On 2010-05-16, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> I understood the claim in question to be a *definition* of parentheses,
>> not merely a statement about their effect.

> Indeed not.  How could it be?  Parentheses are used for all sorts of
> quite different purposes in C: function calls, parameter lists, casts,
> compound literals, declarators... even in some statements.  All these
> can be thought of "other syntax" with nothing to do with grouping in an
> expression.

Yes, I just meant the () "operator".

> My point was simply that there is another way to look at ()s and that it
> is (a) adequate to explain how C's "grouping parentheses" and (b) it is
> interesting in its own right in that it permits one to imagine new
> expression forms that are normally discounted.

Hmm.  I think it's not quite adequate to explain the grouping parentheses,
because there are cases in which it has effects beyond merely changing
grouping, but I can see it as a viable approximation.

Which brings me back to:  The single-sentence description by Schildt is,
IMHO, "incorrect" -- it is not an accurate description.  As a part of a
longer explanation, offered as a description of the net effect, I can see
how it would be useful.

> I would never advocate using the notion I've been defending as a way to
> explain C's "grouping parentheses" in C book.  I was simply defending it
> against an apparent wholesale rejection of the notion.

Ahh, I see.

> When you have said "this is wrong" or "this is confusing" I thought you
> were talking about something I'd said.  Clearly, the above is confusing
> and obviously wrong in many respects, but there is a germ of truth in
> the statement about ()s and precedence.

Ahhh!

Okay, yeah.  I was just arguing that Schildt's explanation is "wrong" -- as
in, if you read that explanation, you do not come away from it with an
accurate understanding of how grouping () work in expressions.

So, to summarize... False:
	Parentheses are an operator which increase the precedence of
	the operations within them.

True:
	Parentheses can be used to group an expression, preventing the
	normal precedence and associativity rules from changing the
	interpretation of that expression when it is used in conjunction
	with other operators.  For instance, normally in C, the expression
	"1 + 2 * 3" evaluates to 7, because the multiplication expression
	is understood to be an operand to the addition operator; one way
	to describe this is that multiplication has "higher precedence" than
	addition.  By contrast, "(1 + 2) * 3" evaluates to 9 because the
	parentheses ensure that 3 is multiplied by the result of adding 1
	and 2.  In effect, parentheses raise the precedence of the operators
	within them, so that the operands within the parentheses always
	bind to those operators, rather than to operators outside the
	parentheses.

(... true, I think, but badly phrased.  Maybe I should try again
after breakfast.)

> I had forgotten that this all started because of a statement in C:TCR.
> That might explain the strength of your opposition to what I thought of
> as an uncontentious observation: that ()s can be seen as syntax whose
> role is to alter the precedence relationship between operators rather
> than as syntax to group sub-expressions.  I saw this exchange as
> off-topic because I was not talking about any application of the idea to
> understanding or parsing C expressions (specifically) whereas I think
> you may have been thinking of it as an extended commentary on Schildt's
> remark.

Yes, that would do it.  I was thinking of it as a discussion, not of the
general habit of using () to group things in expressions, but specifically
of the expression-grouping () in C.

Thanks for sticking with this, I was pretty concerned because usually if
I disagree with you, it implies that I'm missing something significant.
It turns out, I think, to have been context.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 2010-05-16, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
><snip>
>> I'm suspecting that, if I weren't confused by it, I might no longer think
>> it was wrong, but I've been unable to get it to map correctly onto how C
>> expressions work yet.

> Would your last sentence still be true if you deleted the words "how"
> and "work"?  In other words, is your problem with it primarily due to
> what you know about how one or more C compilers parse expression, or it
> with the meaning it gives to expressions independently of how they are
> parsed?

I think the latter.  It seems very significant to me to note that grouping
() really do introduce a whole new expression context, which is in some
ways different from merely changing precedence.  (e.g., the ability to use
comma operators in function arguments -- not that I think that should come
up much).  I think it may be a fair description of all the cases in which
the expression has otherwise the same set of operators and operands --
so, say, not including cases like , in function call argument lists.  I'm
not sure, though, and it just feels like it's missing the point.

But then, to me, "separate expression" is easier to understand than precedence
to begin with.  So I may just be having a hard time mapping things to
precedence.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs <usenet-nospam@seebs.net> writes:

> On 2010-05-16, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Seebs <usenet-nospam@seebs.net> writes:
>><snip>
>>> I'm suspecting that, if I weren't confused by it, I might no longer think
>>> it was wrong, but I've been unable to get it to map correctly onto how C
>>> expressions work yet.
>
>> Would your last sentence still be true if you deleted the words "how"
>> and "work"?  In other words, is your problem with it primarily due to
>> what you know about how one or more C compilers parse expression, or it
>> with the meaning it gives to expressions independently of how they are
>> parsed?
>
> I think the latter.  It seems very significant to me to note that grouping
> () really do introduce a whole new expression context, which is in some
> ways different from merely changing precedence.  (e.g., the ability to use
> comma operators in function arguments -- not that I think that should come
> up much).  I think it may be a fair description of all the cases in which
> the expression has otherwise the same set of operators and operands --
> so, say, not including cases like , in function call argument lists.  I'm
> not sure, though, and it just feels like it's missing the point.

I am pretty sure the function argument case is a red herring: because C
has (at least) 2 meanings for ',' you are forced to use a mechanism
designed for one purpose to achieve another.

That case does, perhaps, point to an area of difference that might clear
things up.  The "()s alter the precedence" idea is intended (at least be
me) as an alternate view of the meaning of an expression.  It is not
intended to describe or replace the syntax of the language.  In other
words, '1,2' is an expression in some cases and not in others, and these
cases must be decided by something else -- the parser.  Having decided
that we have an expression, its meaning can be explained in several ways
-- one of which you don't much like!

I think the reason you don't like it is that it only does half the job.
The grammar of C induces, on any syntactically correct text, a parse
tree that describes both what is and is not an expression *and* what
the operands of every operator are (i.e. their binding).  In that sense
there is no competition, but then I was not putting one up against the
other.

<snip>
-- 
Ben.

On May 16, 11:48=A0am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-05-16, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> > Seebs <usenet-nos...@seebs.net> writes:
> >> But precedence is how you determine the binding of operators -- meanin=
g it
> >> is only conceptually relevant when there is a choice of bindings
> >> available.
> > Sorry, I don't follow this.
>
> Okay, consider:
> =A0 =A0 =A0 =A0 a + b;
> =A0 =A0 =A0 =A0 c * d;
> Precedence has no involvement in how we determine the values of these two
> expressions, because there's no possible choice-of-bindings. =A0Each expr=
ession
> is self-contained.
>
> But in:
> =A0 =A0 =A0 =A0 a + b * c;
> we see that precedence *does* matter, because it's a way of explaining ho=
w
> we resolve ambiguity.
>
> In
> =A0 =A0 =A0 =A0 (a + b) * c;
> there is no precedence at issue; there is no ambiguity about how the oper=
ators
> would bind, and no point at which you have a choice of which of two opera=
tors
> to handle.
>
> > [Big unmarked snip here. =A0Without the example the following reads odd=
ly.]
>
> Sorry, bad habit -- I tend to snip to enough context that you can see
> what was going on if you read the previous post, probably.
>
> >> I dunno. =A0This just seems more complicated to me. =A0I am fine with =
granting
> >> that thinking about () in terms of precedence is interesting, I just d=
on't
> >> think it seems like a good description of what happens.
> > What does happen? =A0If the parser uses YACC, the description of "what
> > happens" takes many pages. =A0If the parse uses another mechanism,
> > something else happens. =A0I don't think there is one privileged view
> > of expressions backed up by "what happens".
>
> I don't think it takes many pages. =A0What happens is the parser looks
> for an "expr" and a following ). =A0That's it; it starts a whole new
> expression-parser, and the whole expression thus parsed becomes the
> value of the atom.
>
> > I have no argument with that despite disagreeing (for example I don't
> > find it either wrong or confusing).
>
> I'm suspecting that, if I weren't confused by it, I might no longer think
> it was wrong, but I've been unable to get it to map correctly onto how C
> expressions work yet.

You were completely unqualified to comment on Schildt because, unlike
him, you had neither taken a computer science class nor written even a
simple parser, and this is why you waste our time in metaphysical
speculation.

How does the parser "look for an expression followed by a )". You do
not know.

Hint: a bottom up parser would look at longer and longer strings to
see if they are expressions and lookahead to find a right parenthesis.
A simple recursive descent (top down) parser would look ahead to find
a balanced right parenthesis and pass the string between the LP and RP
to a "new" parser (a recursive call of the parser routine that looks
for an expression.

This is because when what you call an "atom" is defined in a formal
grammar one of its definitions is "an expression in parentheses".

You waste our time with babbling. Why don't you just go and take a
compiler design class at the undergraduate level at your local
university? They will probably allow you in since you have experience
even though you might have some trouble.

Being able to write a small interpretive compiler separates the men
from the boys. Herb did so in 1989: you have not. But you have the
utter nerve to dismiss his compiler because it was an interpreter and
to describe problems as "first level computer science" when you, by
your own admission, haven't taken any comp sci classes at the
university level.

Write a CALCULATOR. Parse simple mathematical expressions. It will
clear up your confusion as to why Herb uses the notion of "stack" as a
given.

>
> -s
> --
> Copyright 2010, all wrongs reversed. =A0Peter Seebach / usenet-nos...@see=
bs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny picturesht=
tp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On Mon, 10 May 2010 11:56:29 -0700 (PDT), John Bode
<jfbode1029@gmail.com> wrote:
<snip most 'spinoza' related material>
> There is an agreed-upon definition of how the language is *supposed*
> to work; that is the language standard.  Most implementations conform
> closely to this standard, some moreso than others.  There is some slop
> around the edges due to limitations in the implementation environment
> or mistakes on the part of the implementor, but on the whole a
> conforming compiler *should* accept a conforming program and reject a
> non-conforming program.
> 
Not quite. First, a nit: the term 'conforming program' is defined by
the standard in a way that is useless, knowingly so, and 'strictly
conforming' is almost as bad. We've had several tries seeking a term
for the (useful!) category of programs that portably work correctly,
and the least bad IMO was 'clc-compliant'.

More substantively: modulo bugs a conforming implementation should
accept *and correctly execute* a clc-compliant program *unless it's
too big* -- and then as Quality of Implementation it should give an
appropriate diagnostic, although the standard doesn't require it.

On the other side, it must diagnose any program with a syntax error or
constraint violation, but it is permitted to try to 'fix' such program
into a valid and if lucky desired one. And it can have extensions that
users intend and want, but mandate diagnosis in conforming mode. 
And it *may* diagnose other errors, but in general there are many
errors that are not practical to detect and thus cannot be rejected.

IOW I agree with 'accept' mostly but 'reject' mostly not

<snip rest>

"spinoza1111" <spinoza1111@yahoo.com> wrote in message 
news:6bd6d2d2-b8cb-4c16-8a55-646a5a57b203@j12g2000pri.googlegroups.com...

[snip usual festering effluvium]

'Round and 'round and 'round he goes
Backing Schildt is all he knows
Bye bye Nilges

Spewing insults snide and vile
Interlaced with Marxist bile
Bye bye Nilges

No one here attends to what you're saying
They just hear a small sad jackass braying
Can't get past your hate for C
Poor pathetic wannabe
Nilges, bye bye
 

On May 24, 7:10=A0pm, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> news:6bd6d2d2-b8cb-4c16-8a55-646a5a57b203@j12g2000pri.googlegroups.com...
>
> [snip usual festering effluvium]
>
> 'Round and 'round and 'round he goes
> Backing Schildt is all he knows
> Bye bye Nilges
>
> Spewing insults snide and vile
> Interlaced with Marxist bile
> Bye bye Nilges
>
> No one here attends to what you're saying
> They just hear a small sad jackass braying
> Can't get past your hate for C
> Poor pathetic wannabe
> Nilges, bye bye

You've done it now.  He's going to complain that (1) your work is
derivative and therefore inferior to his; and (2) the derivation
implies rampant racism on your part.  At first the source eluded me,
right at the edge of memory, but then I remembered GIYF and had the
obvious answer.  LQTM.

On May 25, 11:51=A0pm, BruceS <bruce...@hotmail.com> wrote:
> On May 24, 7:10=A0pm, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
>
>
>
>
>
> > "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> >news:6bd6d2d2-b8cb-4c16-8a55-646a5a57b203@j12g2000pri.googlegroups.com..=
..
>
> > [snip usual festering effluvium]
>
> > 'Round and 'round and 'round he goes
> > Backing Schildt is all he knows
> > Bye bye Nilges
>
> > Spewing insults snide and vile
> > Interlaced with Marxist bile
> > Bye bye Nilges
>
> > No one here attends to what you're saying
> > They just hear a small sad jackass braying
> > Can't get past your hate for C
> > Poor pathetic wannabe
> > Nilges, bye bye
>
> You've done it now. =A0He's going to complain that (1) your work is
> derivative and therefore inferior to his; and (2) the derivation
> implies rampant racism on your part. =A0At first the source eluded me,
> right at the edge of memory, but then I remembered GIYF and had the
> obvious answer. =A0LQTM.

That ain't my complaint
Although the work is inferior:
What doth it attaint
Is...it hath no metre.

No metre at all, the work of a child
Who can't even find a decent rhyme
It's not free verse, it is tame and not wild
Read it aloud if you have the time.

You'll see hopefully that it stumbles
It limps and it crawls
It's just a series of psychotic mumbles
The work of an infant who whines and who bawls.

Even as, ass, we find no craft
In the C code posted here
This poet *maudit* is worse than daft
If he thinks his poem is aught but queer.

It's totally without vocabulary
The work of a subliterate thug
Filled with self-hatred, a hysterical history
Of a dog who pisses on a fireplug.

In fine, and to sum it up
Poetry isn't rock and roll
In music metric misery is covered up
With sound: here, the fault's obvious...to all.

And because as poetry this is misery
What comes through is a Fascist's hate
A Hitler, a reject, an art school flunkee-outee
Who oughta be locked up by county and state.

Learn you this lesson: don't even try
To compete with me:
You haven't the ability.

On May 25, 10:59=A0am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On May 25, 11:51=A0pm, BruceS <bruce...@hotmail.com> wrote:
>
>
>
> > On May 24, 7:10=A0pm, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
>
> > > "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> > >news:6bd6d2d2-b8cb-4c16-8a55-646a5a57b203@j12g2000pri.googlegroups.com=
....
>
> > > [snip usual festering effluvium]
>
> > > 'Round and 'round and 'round he goes
> > > Backing Schildt is all he knows
> > > Bye bye Nilges
>
> > > Spewing insults snide and vile
> > > Interlaced with Marxist bile
> > > Bye bye Nilges
>
> > > No one here attends to what you're saying
> > > They just hear a small sad jackass braying
> > > Can't get past your hate for C
> > > Poor pathetic wannabe
> > > Nilges, bye bye
>
> > You've done it now. =A0He's going to complain that (1) your work is
> > derivative and therefore inferior to his; and (2) the derivation
> > implies rampant racism on your part. =A0At first the source eluded me,
> > right at the edge of memory, but then I remembered GIYF and had the
> > obvious answer. =A0LQTM.
>
> That ain't my complaint
> Although the work is inferior:
> What doth it attaint
> Is...it hath no metre.

It appears that you missed the reference that I noticed but had to
look up.  It scans fine when you know what you're looking for.  GIYF.
HTH.

"BruceS" <bruces42@hotmail.com> wrote in message
news:6dd832ed-0af0-4bb5-aac6-ffa77f0754b0@c11g2000vbe.googlegroups.com...

[ka-snip]

>
> It appears that you missed the reference that I noticed but had to
> look up.  It scans fine when you know what you're looking for.  GIYF.
> HTH.

Ed and I are approximately the same age, which means the song was
published twenty-something years before we were born. Even so, it's not that
unknown, even today. In fact, just reading the lyrics, even parody lyrics,
almost automatically starts the melody playing, at least in MY head! :-) The
fact that the cultural reference seems to have zoomed right over Ed's head
makes his clueless reply all the sweeter.

Sadly, since my ISP is reportedly dropping NGs sometime this summer, it
probably is "bye bye" to not just Ed , but c.l.c et al. I do have a link to
news.eternal-september.org; not sure how long that will last.  The Google
interface is not even worth consideration.

Ed: "bye bye Nilges"--cudgel thy brains! :-D Or, as BruceS says, GIYF!


 

In article <VEXKn.24943$Ak3.13939@newsfe16.iad>,
 "Bruce C. Baker" <gone_pecan@nowhere.net> wrote:

> Sadly, since my ISP is reportedly dropping NGs sometime this summer, it
> probably is "bye bye" to not just Ed , but c.l.c et al. I do have a link to
> news.eternal-september.org; not sure how long that will last.  The Google
> interface is not even worth consideration.

You could try www.individual.net. Only �10/year, which is what, about $7 
these days? Many of us on uk.comp.sys.mac use that.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

"Bruce C. Baker" <gone_pecan@nowhere.net> writes:
[...]
> Sadly, since my ISP is reportedly dropping NGs sometime this summer, it
> probably is "bye bye" to not just Ed , but c.l.c et al. I do have a link to
> news.eternal-september.org; not sure how long that will last.  The Google
> interface is not even worth consideration.

I've been using news.eternal-september.org for quite a while.  It's
reasonably reliable, thought not 100%.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

"Tim Streater" <timstreater@waitrose.com> wrote in message 
news:timstreater-8A80FD.23095325052010@news.individual.net...

[snip]

> You could try www.individual.net. Only �10/year, which is what, about $7
> these days? Many of us on uk.comp.sys.mac use that.
>

More like $15/yr, if I have the exchange rate right. It's not so much a 
matter of money as the fact that of the five NGs I regularly subscribe to, 
three are Microsoft and are in the process of being terminated along with 
the rest of the MS NGs, one is available via a blog and/or RSS feed, and the 
fifth is all but abandoned.

Nevertheless, thanks for the suggestion.
 

On May 26, 3:26=A0am, BruceS <bruce...@hotmail.com> wrote:
> On May 25, 10:59=A0am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
>
>
>
>
> > On May 25, 11:51=A0pm, BruceS <bruce...@hotmail.com> wrote:
>
> > > On May 24, 7:10=A0pm, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote=
:
>
> > > > "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> > > >news:6bd6d2d2-b8cb-4c16-8a55-646a5a57b203@j12g2000pri.googlegroups.c=
om...
>
> > > > [snip usual festering effluvium]
>
> > > > 'Round and 'round and 'round he goes
> > > > Backing Schildt is all he knows
> > > > Bye bye Nilges
>
> > > > Spewing insults snide and vile
> > > > Interlaced with Marxist bile
> > > > Bye bye Nilges
>
> > > > No one here attends to what you're saying
> > > > They just hear a small sad jackass braying
> > > > Can't get past your hate for C
> > > > Poor pathetic wannabe
> > > > Nilges, bye bye
>
> > > You've done it now. =A0He's going to complain that (1) your work is
> > > derivative and therefore inferior to his; and (2) the derivation
> > > implies rampant racism on your part. =A0At first the source eluded me=
,
> > > right at the edge of memory, but then I remembered GIYF and had the
> > > obvious answer. =A0LQTM.
>
> > That ain't my complaint
> > Although the work is inferior:
> > What doth it attaint
> > Is...it hath no metre.
>
> It appears that you missed the reference that I noticed but had to
> look up. =A0It scans fine when you know what you're looking for. =A0GIYF.
> HTH.

No, I'm sorry, but it doesn't scan
You would know this were you an intelligent man
But of course you're not, you're but a sot
So let me see if I can show you the plan.

"Bye bye Nilges" doesn't scan in any way
And it doesn't fit the lines before
It makes your "poem" the song of a whore
That doesn't say what you want it to say.

In your Pop subconscious, that pile of trash
You see, there's a song by Ann-Margret
It's called "bye bye birdie" I'd hasard, I'd bet
And into your ode it did you smash

Creating the song of a vicious child
Wetting and soiling his pants with hate
Uncouth, savage, without culture but not wild
Rather one that's a ward of the state.

On May 26, 3:26=A0am, BruceS <bruce...@hotmail.com> wrote:
> On May 25, 10:59=A0am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
>
>
>
>
> > On May 25, 11:51=A0pm, BruceS <bruce...@hotmail.com> wrote:
>
> > > On May 24, 7:10=A0pm, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote=
:
>
> > > > "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> > > >news:6bd6d2d2-b8cb-4c16-8a55-646a5a57b203@j12g2000pri.googlegroups.c=
om...
>
> > > > [snip usual festering effluvium]
>
> > > > 'Round and 'round and 'round he goes
> > > > Backing Schildt is all he knows
> > > > Bye bye Nilges
>
> > > > Spewing insults snide and vile
> > > > Interlaced with Marxist bile
> > > > Bye bye Nilges
>
> > > > No one here attends to what you're saying
> > > > They just hear a small sad jackass braying
> > > > Can't get past your hate for C
> > > > Poor pathetic wannabe
> > > > Nilges, bye bye
>
> > > You've done it now. =A0He's going to complain that (1) your work is
> > > derivative and therefore inferior to his; and (2) the derivation
> > > implies rampant racism on your part. =A0At first the source eluded me=
,
> > > right at the edge of memory, but then I remembered GIYF and had the
> > > obvious answer. =A0LQTM.
>
> > That ain't my complaint
> > Although the work is inferior:
> > What doth it attaint
> > Is...it hath no metre.
>
> It appears that you missed the reference that I noticed but had to
> look up. =A0It scans fine when you know what you're looking for. =A0GIYF.
> HTH.

Seriously, if you want to compete with me
In C coding or in poetry
First go and get an education
Cease else your flow: this menstruation.

Major in computer science,
Not psychology, history or in sheer defiance
Of teachers who you hate and hound
Because your learning, it's unsound.

Now, as to poetry.
The Norton Anthology
Which you need to get
Defines it as "writing meant to be read":
Words on paper meant to be said.

Not crooned like an anthem of rock and roll
And that's why your poem it blows
The only way to make it sound any good at all
Is to sing the chorus through your nose.

Another book you need to crack
Is John Lennard's "The Poet's Handbook", Jack.
Companion to the Norton tome
From it you might learn, you gnome
How to do as they do in Rome.

But I won't hang by my thumbs
And I will not wait on tenterhooks
You and your foolish, clueless chums
Don't actually read such things...as books.

Instead you attack authors on Amazon
Like the vicious children that you are
Gang bang rapists you climb upon
The victim to sodomize behind your mental prison bar.

"spinoza1111" <spinoza1111@yahoo.com> wrote in message 
news:a667a913-2fe8-4ffe-ba1d-

[snipparooney]

> "Bye bye Nilges" doesn't scan in any way
> And it doesn't fit the lines before
> It makes your "poem" the song of a whore
> That doesn't say what you want it to say.

"... the song of a whore": Oh, Eddie, you are sooooo close!

Bye bye--/what/?

Avian reference, check. Two syllables, check. Birdie--bzzzt!

C'mon, Ed! Marshall those gray cells!  You're gonna kick yourself when you 
find out how close you are!

Bruce C. Baker (Not to be confused with BruceS)


 

On May 26, 1:16=A0pm, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> news:a667a913-2fe8-4ffe-ba1d-
>
> [snipparooney]
>
> > "Bye bye Nilges" doesn't scan in any way
> > And it doesn't fit the lines before
> > It makes your "poem" the song of a whore
> > That doesn't say what you want it to say.
>
> "... the song of a whore": Oh, Eddie, you are sooooo close!
>
> Bye bye--/what/?
>
> Avian reference, check. Two syllables, check. Birdie--bzzzt!
>
> C'mon, Ed! Marshall those gray cells! =A0You're gonna kick yourself when =
you
> find out how close you are!

Sorry, Brucie, you've lost the game
You took an hour for your attempt
And unless set to musick bad, it's lame
Whereas I in minutes you pre-empt.

You see, the rules are clear
You have to reply in verse
But you've shot your bolt, my dear
And your prose...well, it is worse.

Your single poem probably took you hours
With an online rhyming dictionary
Whereas I sit down and write these flowers
Of verse quite fast, almost...instantaneously.

You're the Peter Seebach of the poet's trade
He's incompetent in C and you, as bard
He worked two months, and of queue.c a mess he made
You labour for an hour and come up with lard.

And every time you post, you are made by me toast
I squash you flat with metre
Meet and fit to subject neat, and this, I'd boast
Is because I ain't you nor Peter.

Geek, lard butt, clueless turd
Give it up, in a word.
You don't know your trade and you don't know grammar
You've been beaned upon the head with my hammer.

>
> Bruce C. Baker (Not to be confused with BruceS)

On May 26, 5:52=A0am, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
> "BruceS" <bruce...@hotmail.com> wrote in message
>
> news:6dd832ed-0af0-4bb5-aac6-ffa77f0754b0@c11g2000vbe.googlegroups.com...
>
> [ka-snip]
>
>
>
> > It appears that you missed the reference that I noticed but had to
> > look up. =A0It scans fine when you know what you're looking for. =A0GIY=
F.
> > HTH.
>
> Ed and I are approximately the same age, which means the song was
> published twenty-something years before we were born. Even so, it's not t=
hat
> unknown, even today. In fact, just reading the lyrics, even parody lyrics=
,
> almost automatically starts the melody playing, at least in MY head! :-) =
The
> fact that the cultural reference seems to have zoomed right over Ed's hea=
d
> makes his clueless reply all the sweeter.

Fuck you, asshole. You meant to reply in verse to show you could do
it, and all that you could dredge up was a popular song.

In verse extempore:

Fuck you, asshole
You're head's up a hole
Filled with trivial junk.
You're a punk,
And if you have a problem with it
You're welcome to pay me a visit.


>
> Sadly, since my ISP is reportedly dropping NGs sometime this summer, it
> probably is "bye bye" to not just Ed , but c.l.c et al. I do have a link =
to
> news.eternal-september.org; not sure how long that will last. =A0The Goog=
le
> interface is not even worth consideration.
>
> Ed: "bye bye Nilges"--cudgel thy brains! :-D Or, as BruceS says, GIYF!

On May 26, 1:52=A0pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On May 26, 5:52=A0am, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
>
>
>
>
>
> > "BruceS" <bruce...@hotmail.com> wrote in message
>
> >news:6dd832ed-0af0-4bb5-aac6-ffa77f0754b0@c11g2000vbe.googlegroups.com..=
..
>
> > [ka-snip]
>
> > > It appears that you missed the reference that I noticed but had to
> > > look up. =A0It scans fine when you know what you're looking for. =A0G=
IYF.
> > > HTH.
>
> > Ed and I are approximately the same age, which means the song was
> > published twenty-something years before we were born. Even so, it's not=
 that
> > unknown, even today. In fact, just reading the lyrics, even parody lyri=
cs,
> > almost automatically starts the melody playing, at least in MY head! :-=
) The
> > fact that the cultural reference seems to have zoomed right over Ed's h=
ead
> > makes his clueless reply all the sweeter.
>
> Fuck you, asshole. You meant to reply in verse to show you could do
> it, and all that you could dredge up was a popular song.
>
> In verse extempore:
>
> Fuck you, asshole
> You're head's up a hole
> Filled with trivial junk.
> You're a punk,
> And if you have a problem with it
> You're welcome to pay me a visit.
>
>
>
>
>
> > Sadly, since my ISP is reportedly dropping NGs sometime this summer, it
> > probably is "bye bye" to not just Ed , but c.l.c et al. I do have a lin=
k to
> > news.eternal-september.org; not sure how long that will last. =A0The Go=
ogle
> > interface is not even worth consideration.
>
> > Ed: "bye bye Nilges"--cudgel thy brains! :-D Or, as BruceS says, GIYF!

It's a pity that I have to be the North Korea of this ng, and nuke all
comers. It could have been avoided had Peter Seebach simply replied to
my email request of last Jan that he discuss the Schildt issue
offline, and spare everyone else this mess.

But jerks like him are afraid of other people and prefer to get their
way by backstabbing.

I have written to Paul Manning at Springer, which now owns Apress, and
asked him to try to persuade Peter to meet with me, perhaps by way of
a Skype video conference, to discuss the matter of Schildt.

But it seems that in Peter Seebach I am dealing with a very troubling
individual. I don't make psychological diagnoses, and stick to the
facts. The facts are that with neither academic qualifications nor
demonstrated programming competence, Peter Seebach speaks outside his
professional competence in re Schildt and this is a very serious legal
matter. Seebach is complicating it by libeling me.

"spinoza1111" <spinoza1111@yahoo.com> wrote in message 
news:52004e29-acda-41f9-a117-a931d1c8aec3@q36g2000prg.googlegroups.com...
> On May 26, 1:16 pm, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
>> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>>
>> news:a667a913-2fe8-4ffe-ba1d-
>>
>> [snipparooney]
>>
>> > "Bye bye Nilges" doesn't scan in any way
>> > And it doesn't fit the lines before
>> > It makes your "poem" the song of a whore
>> > That doesn't say what you want it to say.
>>
>> "... the song of a whore": Oh, Eddie, you are sooooo close!
>>
>> Bye bye--/what/?
>>
>> Avian reference, check. Two syllables, check. Birdie--bzzzt!
>>
>> C'mon, Ed! Marshall those gray cells!  You're gonna kick yourself when 
>> you
>> find out how close you are!
>
> Sorry, Brucie, you've lost the game
> You took an hour for your attempt
> And unless set to musick bad, it's lame
> Whereas I in minutes you pre-empt.
>
> You see, the rules are clear
> You have to reply in verse
> But you've shot your bolt, my dear
> And your prose...well, it is worse.
>
> Your single poem probably took you hours
> With an online rhyming dictionary
> Whereas I sit down and write these flowers
> Of verse quite fast, almost...instantaneously.
>
> You're the Peter Seebach of the poet's trade
> He's incompetent in C and you, as bard
> He worked two months, and of queue.c a mess he made
> You labour for an hour and come up with lard.
>
> And every time you post, you are made by me toast
> I squash you flat with metre
> Meet and fit to subject neat, and this, I'd boast
> Is because I ain't you nor Peter.
>
> Geek, lard butt, clueless turd
> Give it up, in a word.
> You don't know your trade and you don't know grammar
> You've been beaned upon the head with my hammer.

All that creativity expended, and you STILL haven't named that tune!

Pack up all your cares and woe, Edster.  :-) 

 

On May 26, 2:48=A0pm, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> news:52004e29-acda-41f9-a117-a931d1c8aec3@q36g2000prg.googlegroups.com...
>
>
>
>
>
> > On May 26, 1:16 pm, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
> >> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> >> news:a667a913-2fe8-4ffe-ba1d-
>
> >> [snipparooney]
>
> >> > "Bye bye Nilges" doesn't scan in any way
> >> > And it doesn't fit the lines before
> >> > It makes your "poem" the song of a whore
> >> > That doesn't say what you want it to say.
>
> >> "... the song of a whore": Oh, Eddie, you are sooooo close!
>
> >> Bye bye--/what/?
>
> >> Avian reference, check. Two syllables, check. Birdie--bzzzt!
>
> >> C'mon, Ed! Marshall those gray cells! =A0You're gonna kick yourself wh=
en
> >> you
> >> find out how close you are!
>
> > Sorry, Brucie, you've lost the game
> > You took an hour for your attempt
> > And unless set to musick bad, it's lame
> > Whereas I in minutes you pre-empt.
>
> > You see, the rules are clear
> > You have to reply in verse
> > But you've shot your bolt, my dear
> > And your prose...well, it is worse.
>
> > Your single poem probably took you hours
> > With an online rhyming dictionary
> > Whereas I sit down and write these flowers
> > Of verse quite fast, almost...instantaneously.
>
> > You're the Peter Seebach of the poet's trade
> > He's incompetent in C and you, as bard
> > He worked two months, and of queue.c a mess he made
> > You labour for an hour and come up with lard.
>
> > And every time you post, you are made by me toast
> > I squash you flat with metre
> > Meet and fit to subject neat, and this, I'd boast
> > Is because I ain't you nor Peter.
>
> > Geek, lard butt, clueless turd
> > Give it up, in a word.
> > You don't know your trade and you don't know grammar
> > You've been beaned upon the head with my hammer.
>
> All that creativity expended, and you STILL haven't named that tune!
>

You missed where I did so, Dumbo
Your ignorance it is supersize: it's jumbo
I said it was "bye bye birdie" already
And you missed it, lard butt, and my name ain't Eddie.

In article <MdZKn.12424$7d5.2412@newsfe17.iad>,
 "Bruce C. Baker" <gone_pecan@nowhere.net> wrote:

> "Tim Streater" <timstreater@waitrose.com> wrote in message 
> news:timstreater-8A80FD.23095325052010@news.individual.net...
> 
> [snip]
> 
> > You could try www.individual.net. Only �10/year, which is what, about $7
> > these days? Many of us on uk.comp.sys.mac use that.
> >
> 
> More like $15/yr, if I have the exchange rate right.

Yes, my mistake. I'm not following the exchange rates properly these 
days.

> It's not so much a 
> matter of money as the fact that of the five NGs I regularly subscribe to, 
> three are Microsoft and are in the process of being terminated along with 
> the rest of the MS NGs, one is available via a blog and/or RSS feed, and the 
> fifth is all but abandoned.
> 
> Nevertheless, thanks for the suggestion.

You're welcome. Shame to see you go.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

"spinoza1111" <spinoza1111@yahoo.com> wrote in message 
news:15d2f4a4-2990-44e4-bcaf-f4060f4916c3@y18g2000prn.googlegroups.com...

[el snippo]

> You missed where I did so, Dumbo
> Your ignorance it is supersize: it's jumbo
> I said it was "bye bye birdie" already
> And you missed it, lard butt, and my name ain't Eddie.

And not only did you miss where I explicitly told you that it WASN'T "bye 
bye birdie", you snipped the neon-flashing hint that I gave you! GIYF!

Name that tune correctly, Eduardito, or admit defeat.




 

On May 26, 5:07=A0pm, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> news:15d2f4a4-2990-44e4-bcaf-f4060f4916c3@y18g2000prn.googlegroups.com...
>
> [el snippo]
>
> > You missed where I did so, Dumbo
> > Your ignorance it is supersize: it's jumbo
> > I said it was "bye bye birdie" already
> > And you missed it, lard butt, and my name ain't Eddie.
>
> And not only did you miss where I explicitly told you that it WASN'T "bye
> bye birdie", you snipped the neon-flashing hint that I gave you! GIYF!
>
> Name that tune correctly, Eduardito, or admit defeat.

That's not a game I care to play
You've shown us that you can't write verse worth dick
And to cover up the failure of your little display
You've made this a game show: a stupid trick.

But I've left the game show long ago
Working in stinking little programming shops
With stunted "men" who ho
Their stunted skilz by drips and drops.

They cannot even bother to take a class
Computer science makes them into an ass
So they major in psychology
To avoid getting a B, or C, or D

On May 26, 4:52=A0pm, Tim Streater <timstrea...@waitrose.com> wrote:
> In article <MdZKn.12424$7d5.2...@newsfe17.iad>,
> =A0"Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
>
> > "Tim Streater" <timstrea...@waitrose.com> wrote in message
> >news:timstreater-8A80FD.23095325052010@news.individual.net...
>
> > [snip]
>
> > > You could trywww.individual.net. Only =A410/year, which is what, abou=
t $7
> > > these days? Many of us on uk.comp.sys.mac use that.
>
> > More like $15/yr, if I have the exchange rate right.
>
> Yes, my mistake. I'm not following the exchange rates properly these
> days.
>
> > It's not so much a
> > matter of money as the fact that of the five NGs I regularly subscribe =
to,
> > three are Microsoft and are in the process of being terminated along wi=
th
> > the rest of the MS NGs, one is available via a blog and/or RSS feed, an=
d the
> > fifth is all but abandoned.
>
> > Nevertheless, thanks for the suggestion.
>
> You're welcome. Shame to see you go.

But he doesn't go...does he
He's first got to prove his "masculinity"
By trying and failing...to silence me.
He'll be here awhile...he'll be here forever and a day
Just to still his secret fear that he's queer, and homo, and gay.

>
> --
> Tim
>
> "That excessive bail ought not to be required, nor excessive fines impose=
d,
> nor cruel and unusual punishments inflicted" =A0-- =A0Bill of Rights 1689

On Wed, 26 May 2010 05:52:50 -0700 (PDT)
spinoza1111 <spinoza1111@yahoo.com> wrote:

> That's not a game I care to play
> You've shown us that you can't write verse worth dick
> And to cover up the failure of your little display
> You've made this a game show: a stupid trick.

Douglas Adams was wrong; there are at least two producers of "poetry"
worse than the Bogons.

B.

On May 26, 9:00=A0pm, Rob Kendrick <n...@rjek.com> wrote:
> On Wed, 26 May 2010 05:52:50 -0700 (PDT)
>
> spinoza1111<spinoza1...@yahoo.com> wrote:
> > That's not a game I care to play
> > You've shown us that you can't write verse worth dick
> > And to cover up the failure of your little display
> > You've made this a game show: a stupid trick.
>
> Douglas Adams was wrong; there are at least two producers of "poetry"
> worse than the Bogons.

All poetry will be read as "bad" today
Just as good food is to he whose health is shot
Nonetheless, you cannot gainsay
The fact I can write it and thou can not.

The sick man eats at McDonald's
Fills he his face with bacon and salt
Fruit and veggies him appalls
Feeds he on garbage 'til he's lame and halt.

Likewise here good programming style is thought queer
You guys want to see incompetence
You think it's cute: it's ability you fear
It's your narcissism's recompense.

You see through the filthy lens of Pop culture
Fed to you for fifty years
Douglas Adams? Wow that's deep: a vulture
Regurgitating technical fantasies to still your fears.

Everything must be shiny, shrink wrapped, and reified
Else you see yourself and wake from a dream denied.

>
> B.

On May 26, 4:51=A0pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On May 26, 2:48=A0pm, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
>
>
>
>
>
> > "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> >news:52004e29-acda-41f9-a117-a931d1c8aec3@q36g2000prg.googlegroups.com..=
..
>
> > > On May 26, 1:16 pm, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
> > >> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> > >> news:a667a913-2fe8-4ffe-ba1d-
>
> > >> [snipparooney]
>
> > >> > "Bye bye Nilges" doesn't scan in any way
> > >> > And it doesn't fit the lines before
> > >> > It makes your "poem" the song of a whore
> > >> > That doesn't say what you want it to say.
>
> > >> "... the song of a whore": Oh, Eddie, you are sooooo close!
>
> > >> Bye bye--/what/?
>
> > >> Avian reference, check. Two syllables, check. Birdie--bzzzt!
>
> > >> C'mon, Ed! Marshall those gray cells! =A0You're gonna kick yourself =
when
> > >> you
> > >> find out how close you are!
>
> > > Sorry, Brucie, you've lost the game
> > > You took an hour for your attempt
> > > And unless set to musick bad, it's lame
> > > Whereas I in minutes you pre-empt.
>
> > > You see, the rules are clear
> > > You have to reply in verse
> > > But you've shot your bolt, my dear
> > > And your prose...well, it is worse.
>
> > > Your single poem probably took you hours
> > > With an online rhyming dictionary
> > > Whereas I sit down and write these flowers
> > > Of verse quite fast, almost...instantaneously.
>
> > > You're the Peter Seebach of the poet's trade
> > > He's incompetent in C and you, as bard
> > > He worked two months, and of queue.c a mess he made
> > > You labour for an hour and come up with lard.
>
> > > And every time you post, you are made by me toast
> > > I squash you flat with metre
> > > Meet and fit to subject neat, and this, I'd boast
> > > Is because I ain't you nor Peter.
>
> > > Geek, lard butt, clueless turd
> > > Give it up, in a word.
> > > You don't know your trade and you don't know grammar
> > > You've been beaned upon the head with my hammer.
>
> > All that creativity expended, and you STILL haven't named that tune!
>
> You missed where I did so, Dumbo
> Your ignorance it is supersize: it's jumbo
> I said it was "bye bye birdie" already
> And you missed it, lard butt, and my name ain't Eddie.

Oh? I got it wrong? Yawn.
Get this, and get it straight, little one:
When I hear the words "popular 'culture'"
I reach for my gun.

Rob Kendrick wrote:
) Douglas Adams was wrong; there are at least two producers of "poetry"
) worse than the Bogons.

You should go read the book again, Vogon Poetry is considered
"the third worst poetry in the universe".


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

On 2010-05-26, Bruce C. Baker <gone_pecan@nowhere.net> wrote:
> All that creativity expended, and you STILL haven't named that tune!

Furthermore, unless you're Ogden Nash, rhyming and meter that forced aren't
funny.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

"spinoza1111" <spinoza1111@yahoo.com> wrote in message
news:57172bd2-f09f-448a-bc98-b17deaced9da@v29g2000prb.googlegroups.com...
> On May 26, 4:51 pm, spinoza1111 <spinoza1...@yahoo.com> wrote:

[effluvium elided]

> Oh? I got it wrong? Yawn.
> Get this, and get it straight, little one:
> When I hear the words "popular 'culture'"
> I reach for my gun.

Well, I suppose it was too much to expect that an exquisitely sophisticated
/boulevardier/ such as yourself would be familiar with the No. 16 hit of
1926:

http://en.wikipedia.org/wiki/Bye_Bye_Blackbird

A veritable earwig of a song, at least for we of the unwashed masses.

EPIC FAIL, Eddie!


 

"Bruce C. Baker" <gone_pecan@nowhere.net> writes:
> "spinoza1111" <spinoza1111@yahoo.com> wrote in message
> news:57172bd2-f09f-448a-bc98-b17deaced9da@v29g2000prb.googlegroups.com...
[snip]
> Well, I suppose it was too much to expect that an exquisitely sophisticated
> /boulevardier/ such as yourself would be familiar with the No. 16 hit of
> 1926:
>
> http://en.wikipedia.org/wiki/Bye_Bye_Blackbird
>
> A veritable earwig of a song, at least for we of the unwashed masses.
>
> EPIC FAIL, Eddie!

Bruce, are you here for the sole purpose of taunting (and thereby
encouraging) one of our resident trolls, or do you have any interest
in the C programming language, which is what we try to discuss here?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

"spinoza1111" <spinoza1111@yahoo.com> wrote in message 
news:2b65e2db-180a-43db-acfb-3490f7b427d0@t14g2000prm.googlegroups.com...

[...]

> But he doesn't go...does he
> He's first got to prove his "masculinity"
> By trying and failing...to silence me.

Far from trying to silence you, Eddie boy, I've been doing my darnedest to 
elicit from you the name of the song on which my lyrics are based.

> He'll be here awhile...he'll be here forever and a day
> Just to still his secret fear that he's queer, and homo, and gay.

Projecting are we, Eduardo, maybe just a little?

When my ISP turns off the USENET tap, I'm gonna miss you, Ed. You're the 
living embodiment of the fine line between genius and madness.


 

On Wed, 26 May 2010 15:59:59 +0000 (UTC)
Willem <willem@turtle.stack.nl> wrote:

> Rob Kendrick wrote:
> ) Douglas Adams was wrong; there are at least two producers of
> "poetry" ) worse than the Bogons.
> 
> You should go read the book again, Vogon Poetry is considered
> "the third worst poetry in the universe".

Yes, but the creators of the second worse are all extinct, because their
intestines throttled their brains, I though? >:)

B.

"Keith Thompson" <kst-u@mib.org> wrote in message
news:ln39xe35lf.fsf@nuthaus.mib.org...

[...]

> Bruce, are you here for the sole purpose of taunting (and thereby
> encouraging) one of our resident trolls, or do you have any interest
> in the C programming language, which is what we try to discuss here?

I plead guilty to taunting, but with an explanation, your honor!

Over the last decade I've watched as Ed Nilges in his various USENET avatars
has poisoned  and in at least one case (comp.programming), almost
single-handedly destroyed one NG after another.

The best response to Ed would be to totally ignore him, but even people who
should know better treat him seriously.

Short of pretending he doesn't exist, the best way to handle Ed is to drown
him in mockery. Unfortunately, as this thread has demonstrated, even that
has no effect on the Edster. When it comes to self-absorbed, fulminating
vileness, the man is a force of nature.

To repeat what I said else-thread, my ISP is about to pull the plug on NGs.
Knowing that my time here is short, I felt the need to tie up this
particular loose end. I forget what the psycho-babble buzz-phrase is for
this; sorry.

As I've said many times in other NGs, the best and most humane way to handle
Ed is to IGNORE HIM! I will now proceed to follow my own excellent advice.

One more thing: Do I have any interest in C programming? Why, C is my middle
name! :-D




 

On 2010-05-26, Keith Thompson <kst-u@mib.org> wrote:
> Bruce, are you here for the sole purpose of taunting (and thereby
> encouraging) one of our resident trolls, or do you have any interest
> in the C programming language, which is what we try to discuss here?

I would consider a discussion of 1926 pop songs to be a noticeable movement
in the direction of topicality from the rest of the Nilges thread, so I'm
inclined to reserve judgement and see whether the improvement continues.

So, obC:

Speaking of rhyme... How do you pronounce C if you have to read it for
some reason?  Is "char" pronounced like the verb "char", the noun "car", or
the verb "care"?  (I'm pretty close to "care", with just a hint of an h in
there, because I pronounce it like the first syllable of "character".)

What are the names of the punctuation marks?  Are those "braces" or "squiggly
brackets"?  Is it "open paren", "open parens", or "open parenthesis"?

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs <usenet-nospam@seebs.net> writes:
[...]
> So, obC:
>
> Speaking of rhyme... How do you pronounce C if you have to read it for
> some reason?  Is "char" pronounced like the verb "char", the noun "car", or
> the verb "care"?  (I'm pretty close to "care", with just a hint of an h in
> there, because I pronounce it like the first syllable of "character".)

I pronounce it (mostly in my head) like the first syllable of
"character", but I know plenty of people who pronounce it like the
verb "char".

> What are the names of the punctuation marks?  Are those "braces" or
> "squiggly brackets"?  Is it "open paren", "open parens", or "open
> parenthesis"?

() parentheses
[] brackets (square brackets if I want to be more explicit)
{} braces   (curly braces if I want to be more explicit)

I think UK English tends to use the words differently (I don't recall
the details), which is why I add the "square" or "curly" modifier (or
even "round" for parentheses) if there's any risk of misunderstanding.

I note that Unicode uses the following terms (reference:
<http://unicode.org/Public/UNIDATA/UnicodeData.txt>):

( LEFT PARENTHESIS,     OPENING PARENTHESIS
) RIGHT PARENTHESIS,    CLOSING PARENTHESIS
[ LEFT SQUARE BRACKET,  OPENING SQUARE BRACKET
] RIGHT SQUARE BRACKET, CLOSING SQUARE BRACKET
{ LEFT CURLY BRACKET,   OPENING CURLY BRACKET
} RIGHT CURLY BRACKET,  CLOSING CURLY BRACKET

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

"Seebs" <usenet-nospam@seebs.net> wrote in message 
news:slrnhvqrui.la7.usenet-nospam@guild.seebs.net...

[...]

In a pathetic attempt to somehow redeem myself while I still have the 
chance:

> So, obC:
>
> Speaking of rhyme... How do you pronounce C if you have to read it for
> some reason?  Is "char" pronounced like the verb "char", the noun "car", 
> or
> the verb "care"?  (I'm pretty close to "care", with just a hint of an h in
> there, because I pronounce it like the first syllable of "character".)

"Care". I've always had the unspoken suspicion that those who pronounced it 
"char" or "car" didn't possess the attention to detail commensurate with 
being a really good programmer (let the flames begin! :-) )

>
> What are the names of the punctuation marks?  Are those "braces" or 
> "squiggly
> brackets"?  Is it "open paren", "open parens", or "open parenthesis"?

(): parentheses; <>: angle brackets; []: square brackets; {}: curly 
brackets, or sometimes just "curlies".

"Open paren", "left angle bracket", "left square bracket", "left curly 
bracket".










 

On May 27, 12:01=A0am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-05-26, Bruce C. Baker <gone_pe...@nowhere.net> wrote:
>
> > All that creativity expended, and you STILL haven't named that tune!
>
> Furthermore, unless you're Ogden Nash, rhyming and meter that forced aren=
't
> funny.

Oh yes they are: http://spinoza1111.wordpress.com/2009/01/23/ode-to-german-=
humor/

"To many people, German humor/Is about as funny as a malignant tumor"

Not just anyone can produce this: you have to be literate (it's not a
"technical skill").

In fine:

Familiar indeed I am
With how people learn to good poetry slam
In bonehead English class,
By sayin', "duh, it does not scan"
Which means "I can't read poetry...not even in the can".

In the middling sort of university
People learn to say "verbosity"
As an excuse for their illiteracy
As a coverup for their inability.
And they learn some pompous talk about how "it don't scan"
Because actually reading poetry is too hard for them...they lack
attention span.

In a similar manner....in a similar way
Incompetent programmers confronted with good code usually say hey
I'm confused, ergo it is bad code...get a load
Of these identifiers, they are too long.
It's all wrong.

>
> -s
> --
> Copyright 2010, all wrongs reversed. =A0Peter Seebach / usenet-nos...@see=
bs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny picturesht=
tp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On May 27, 1:54=A0am, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> news:57172bd2-f09f-448a-bc98-b17deaced9da@v29g2000prb.googlegroups.com...
>
> > On May 26, 4:51 pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
> [effluvium elided]
>
> > Oh? I got it wrong? Yawn.
> > Get this, and get it straight, little one:
> > When I hear the words "popular 'culture'"
> > I reach for my gun.
>
> Well, I suppose it was too much to expect that an exquisitely sophisticat=
ed
> /boulevardier/ such as yourself would be familiar with the No. 16 hit of
> 1926:
>
> http://en.wikipedia.org/wiki/Bye_Bye_Blackbird
>
> A veritable earwig of a song, at least for we of the unwashed masses.
>
> EPIC FAIL, Eddie!

I thought you were leaving?
Guess not, sot:
You're heaving
With rage...although you have naught
To say in any way.

You failed to reply adequately in verse
And what is far worse
Your memory is restricted to popular culture.
It's a toxic waste dump from which you cry
I I I.

On May 27, 2:01=A0am, Keith Thompson <ks...@mib.org> wrote:
> "Bruce C. Baker" <gone_pe...@nowhere.net> writes:
>
> > "spinoza1111" <spinoza1...@yahoo.com> wrote in message
> >news:57172bd2-f09f-448a-bc98-b17deaced9da@v29g2000prb.googlegroups.com..=
..
> [snip]
> > Well, I suppose it was too much to expect that an exquisitely sophistic=
ated
> > /boulevardier/ such as yourself would be familiar with the No. 16 hit o=
f
> > 1926:
>
> >http://en.wikipedia.org/wiki/Bye_Bye_Blackbird
>
> > A veritable earwig of a song, at least for we of the unwashed masses.
>
> > EPIC FAIL, Eddie!
>
> Bruce, are you here for the sole purpose of taunting (and thereby
> encouraging) one of our resident trolls, or do you have any interest
> in the C programming language, which is what we try to discuss here?

There is a pompous turd named Kiki
Who's never on topic...in actuality
But us he doth admonish
The troll through silence to abolish
That pompous turd named Kiki

But, that pompous turd named Kiki
Thereby falls into a situation quite contradicti
By saying what under his own rule cannot be said
He proves he's off his rocker and off his head
That pompous bird named Kiki

The situation, is Godelian
We're Turing some sort of perihelion
Of what happens when you
Try to state a self-reflexive rule...and rue
The day
You started to speak in this way.

>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org =A0<http://www.ghoti.net/~=
kst>
> Nokia
> "We must do something. =A0This is something. =A0Therefore, we must do thi=
s."
> =A0 =A0 -- Antony Jay and Jonathan Lynn, "Yes Minister"

On May 27, 2:08=A0am, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> news:2b65e2db-180a-43db-acfb-3490f7b427d0@t14g2000prm.googlegroups.com...
>
> [...]
>
> > But he doesn't go...does he
> > He's first got to prove his "masculinity"
> > By trying and failing...to silence me.
>
> Far from trying to silence you, Eddie boy, I've been doing my darnedest t=
o
> elicit from you the name of the song on which my lyrics are based.

Having lost the poetry toss
The fools
Change the rules
>
> > He'll be here awhile...he'll be here forever and a day
> > Just to still his secret fear that he's queer, and homo, and gay.
>
> Projecting are we, Eduardo, maybe just a little?
>
> When my ISP turns off the USENET tap, I'm gonna miss you, Ed. You're the
> living embodiment of the fine line between genius and madness.

On May 27, 2:45=A0am, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
> "Keith Thompson" <ks...@mib.org> wrote in message
>
> news:ln39xe35lf.fsf@nuthaus.mib.org...
>
> [...]
>
> > Bruce, are you here for the sole purpose of taunting (and thereby
> > encouraging) one of our resident trolls, or do you have any interest
> > in the C programming language, which is what we try to discuss here?
>
> I plead guilty to taunting, but with an explanation, your honor!
>
> Over the last decade I've watched as Ed Nilges in his various USENET avat=
ars
> has poisoned =A0and in at least one case (comp.programming), almost
> single-handedly destroyed one NG after another.
>
> The best response to Ed would be to totally ignore him, but even people w=
ho
> should know better treat him seriously.
>
> Short of pretending he doesn't exist, the best way to handle Ed is to dro=
wn
> him in mockery. Unfortunately, as this thread has demonstrated, even that
> has no effect on the Edster. When it comes to self-absorbed, fulminating
> vileness, the man is a force of nature.
>
> To repeat what I said else-thread, my ISP is about to pull the plug on NG=
s.
> Knowing that my time here is short, I felt the need to tie up this
> particular loose end. I forget what the psycho-babble buzz-phrase is for
> this; sorry.
>
> As I've said many times in other NGs, the best and most humane way to han=
dle
> Ed is to IGNORE HIM! I will now proceed to follow my own excellent advice=
..
>
> One more thing: Do I have any interest in C programming? Why, C is my mid=
dle
> name! :-D

The rage, the rage of the defeated
Rings out in pompous nonsense
He tries a valediction
But it's only a puny malediction.

On May 26, 11:59=A0pm, Willem <wil...@turtle.stack.nl> wrote:
> Rob Kendrick wrote:
>
> ) Douglas Adams was wrong; there are at least two producers of "poetry"
> ) worse than the Bogons.
>
> You should go read the book again, Vogon Poetry is considered
> "the third worst poetry in the universe".

To the techno-Fascist and the mob
And to the garden variety slob
All poetry is bad...it grates his dirty ear
The music of words is the music of fear.

The Roman mob, in Julius Caesar,
Comes upon Cinna the harmless poet
The mob has what can only be called a seizure
They claim he's Cinna the conspirator, they know it.

But when the poet cries, I am Cinna the poet
The mob is filled with lust of blood and cannot stop
"Kill him for his bad verses", so goes it
They make him hop and they string him up.

The goat-song grates upon the ear, and is meant to
Its one voice against the community
Where "community" isn't always great:
It can be constructed by greed, fear, and hate.
Cinna and Dionysius must be sacrificed
Because of your ignorance...they must be iced.

But I would remark upon how it is
That sans poetry ignorance, is bliss:
How without a moral imagination
Normalized deviance pervades the nation.

British Petroleum couldn't take the time
To replace a battery in a shut off switch
Now, like apes, they try cement and lime
To plug a hole to make a stitch.

I know these men, they're the loudmouthed thugs
Who won't listen but tell you to
Who think they're such fire plugs
When they say they don't give a rat's ass about you.

Their hired hands are worse, they are deviant men
Selected because they can be controlled
Some of them completely without qualifications, and then,
Some of them with qualifications that are just...old.

They drive the schedule...they ignore real problems
They wouldn't double-hull the Exxon Valdez
And when you object, pal, you're academic
Which means you don't have a dick like them.

And when they come a cropper, and fuck up
Their code fails if percent is not followed by p
The containment dome is filled with ice and gas
It's not their fault...'tis someone else, you see.

And if you take a stand like a genuine man
They lead the chorus of fear and hate.
Humanity they can no longer stand
The daemon corporation is now their state.


>
> SaSW, Willem
> --
> Disclaimer: I am in no way responsible for any of the statements
> =A0 =A0 =A0 =A0 =A0 =A0 made in the above text. For all I know I might be
> =A0 =A0 =A0 =A0 =A0 =A0 drugged or something..
> =A0 =A0 =A0 =A0 =A0 =A0 No I'm not paranoid. You all think I'm paranoid, =
don't you !
> #EOT

Keith Thompson <kst-u@mib.org> writes:
> Seebs <usenet-nospam@seebs.net> writes:
> [...]
>> So, obC:
>>
>> Speaking of rhyme... How do you pronounce C if you have to read it for
>> some reason?  Is "char" pronounced like the verb "char", the noun "car", or
>> the verb "care"?  (I'm pretty close to "care", with just a hint of an h in
>> there, because I pronounce it like the first syllable of "character".)
>
> I pronounce it (mostly in my head) like the first syllable of
> "character", but I know plenty of people who pronounce it like the
> verb "char".
>
>> What are the names of the punctuation marks?  Are those "braces" or
>> "squiggly brackets"?  Is it "open paren", "open parens", or "open
>> parenthesis"?
>
> () parentheses
> [] brackets (square brackets if I want to be more explicit)
> {} braces   (curly braces if I want to be more explicit)
>
> I think UK English tends to use the words differently (I don't recall
> the details), which is why I add the "square" or "curly" modifier (or
> even "round" for parentheses) if there's any risk of misunderstanding.

All of them are some kind of bracket by name, because they
bracket by nature. However, they also are also found by the
brace, and brace, so they're braces too.

When used in text, most are used to parenthesise[1]. When used
in code, almost none are ever used to parenthesise. Calling 
the '(' and ')' in '(a+b)*c' 'parentheses' always seems pretty
dumb to me, as there's nothing parenthetical about 'a+b'.

Phil
[1 - Even that '1' in the square brackets is parenthetical, it 
can be removed without altering the meaning of the text it is 
found within.]
-- 
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

On 26 May, 20:26, Keith Thompson <ks...@mib.org> wrote:
> Seebs <usenet-nos...@seebs.net> writes:

> > Speaking of rhyme... How do you pronounce C if you have to read it for
> > some reason? =A0

[s-ee]

> > Is "char" pronounced like the verb "char",

that's what i do

> > the noun "car",

[kar] I've heard

> > or the verb "care"? =A0

only scousers would do that

> > (I'm pretty close to "care", with just a hint of an h in
> > there, because I pronounce it like the first syllable of "character".)

with my accept (northern uk) there's no trace of an "h" in character
[kar-ak-ter]

> I pronounce it (mostly in my head) like the first syllable of
> "character", but I know plenty of people who pronounce it like the
> verb "char".
>
> > What are the names of the punctuation marks? =A0Are those "braces" or
> > "squiggly brackets"? =A0Is it "open paren", "open parens", or "open
> > parenthesis"?
>
> () parentheses
> [] brackets (square brackets if I want to be more explicit)
> {} braces =A0 (curly braces if I want to be more explicit)
>
> I think UK English tends to use the words differently (I don't recall
> the details), which is why I add the "square" or "curly" modifier (or
> even "round" for parentheses) if there's any risk of misunderstanding.

brackets (or round brackets) or parentheses
square brackets
curly brackets

I don't think a UK non-programmer would understand what braces were (a
way to sell game birds?, a way keep your trousers up? orthodontal
correction? several stiff drinks?)


> I note that Unicode uses the following terms (reference:
> <http://unicode.org/Public/UNIDATA/UnicodeData.txt>):
>
> ( LEFT PARENTHESIS, =A0 =A0 OPENING PARENTHESIS
> ) RIGHT PARENTHESIS, =A0 =A0CLOSING PARENTHESIS
> [ LEFT SQUARE BRACKET, =A0OPENING SQUARE BRACKET
> ] RIGHT SQUARE BRACKET, CLOSING SQUARE BRACKET
> { LEFT CURLY BRACKET, =A0 OPENING CURLY BRACKET
>
> } RIGHT CURLY BRACKET, =A0CLOSING CURLY BRACKET

On May 27, 3:46=A0am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 26 May, 20:26, Keith Thompson <ks...@mib.org> wrote:
>
> > Seebs <usenet-nos...@seebs.net> writes:
> > > Speaking of rhyme... How do you pronounce C if you have to read it fo=
r
> > > some reason? =A0
>
> [s-ee]
>
> > > Is "char" pronounced like the verb "char",
>
> that's what i do
>
> > > the noun "car",
>
> [kar] I've heard
>
> > > or the verb "care"? =A0
>
> only scousers would do that

and Yanks.  There's more to this Earth than BG, you know.

>
> > > (I'm pretty close to "care", with just a hint of an h in
> > > there, because I pronounce it like the first syllable of "character".=
)
>
> with my accept (northern uk) there's no trace of an "h" in character
> [kar-ak-ter]

None in mine either, but in my case that first syllable is
indistinguishable from the verb "care".
<snip>

On May 27, 2:01=A0am, Keith Thompson <ks...@mib.org> wrote:
> "Bruce C. Baker" <gone_pe...@nowhere.net> writes:
>
> > "spinoza1111" <spinoza1...@yahoo.com> wrote in message
> >news:57172bd2-f09f-448a-bc98-b17deaced9da@v29g2000prb.googlegroups.com..=
..
> [snip]
> > Well, I suppose it was too much to expect that an exquisitely sophistic=
ated
> > /boulevardier/ such as yourself would be familiar with the No. 16 hit o=
f
> > 1926:
>
> >http://en.wikipedia.org/wiki/Bye_Bye_Blackbird
>
> > A veritable earwig of a song, at least for we of the unwashed masses.
>
> > EPIC FAIL, Eddie!
>
> Bruce, are you here for the sole purpose of taunting (and thereby
> encouraging) one of our resident trolls, or do you have any interest
> in the C programming language, which is what we try to discuss here?

According to Jaron Lanier ("You Are Not a Gadget"), a "troll" is
anonymous, so I cannot be one, since I take responsibility for what I
say, and you know who I am: wrote a published a successful Apress
title, lives in Hong Kong, is now a teacher, etc.

I can only conclude that you use this word because you're too cowardly
to fashion a racist label.

The "troll", like the Muslim, is the new "Jew". It "scans" in the same
way, and it defines the person who need not be the recipient of common
decency and courtesy, and who others laud or befriend at the cost of
being likewise labeled. Furthermore, like the "Jew", the "troll" is
sourly viewed as a free spirit by artisans and clerks chained to
meaningless jobs.

I have contributed too much for free to this newsgroup in the form of
on-topic technical discussion to be the subject of your cowardly
label. If you continue this name-calling I may contact your employer.


>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org =A0<http://www.ghoti.net/~=
kst>
> Nokia
> "We must do something. =A0This is something. =A0Therefore, we must do thi=
s."
> =A0 =A0 -- Antony Jay and Jonathan Lynn, "Yes Minister"

On May 27, 2:45=A0am, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
> "Keith Thompson" <ks...@mib.org> wrote in message
>
> news:ln39xe35lf.fsf@nuthaus.mib.org...
>
> [...]
>
> > Bruce, are you here for the sole purpose of taunting (and thereby
> > encouraging) one of our resident trolls, or do you have any interest
> > in the C programming language, which is what we try to discuss here?
>
> I plead guilty to taunting, but with an explanation, your honor!
>
> Over the last decade I've watched as EdNilgesin his various USENET avatar=
s
> has poisoned =A0and in at least one case (comp.programming), almost
> single-handedly destroyed one NG after another.
>
> The best response to Ed would be to totally ignore him, but even people w=
ho
> should know better treat him seriously.
>
> Short of pretending he doesn't exist, the best way to handle Ed is to dro=
wn
> him in mockery. Unfortunately, as this thread has demonstrated, even that
> has no effect on the Edster. When it comes to self-absorbed, fulminating
> vileness, the man is a force of nature.
>
> To repeat what I said else-thread, my ISP is about to pull the plug on NG=
s.
> Knowing that my time here is short, I felt the need to tie up this
> particular loose end. I forget what the psycho-babble buzz-phrase is for
> this; sorry.
>
> As I've said many times in other NGs, the best and most humane way to han=
dle
> Ed is to IGNORE HIM! I will now proceed to follow my own excellent advice=
..
>
> One more thing: Do I have any interest in C programming? Why, C is my mid=
dle
> name! :-D

Note that these tirades *contra* Nilges never name specifics, but only
propagate abstract charges: that I am deliberately disruptive person,
ignorant, and incompetent.

Whereas when I talk about Seebach I take care almost always to
enumerate specific charges germane to his standing here:

1.  He has not taken any computer science classes at the university
level, yet has attacked an author with the MSCS and BS in computer
science,

2.  And, he is not an untutored programming genius such that we could
ignore his lack of preparation, for he made silly errors in the attack
(claiming that one should not use the concept of "stack" to explain
runtime) and posted incompetent vanity code, which makes it clear that
he's an autodidact.

3.  The vanity code includes an off by one strlen, a search for %p
that also finds percent anything,  and unstructured switch statements

4.  In trying and failing to demonstrate that it's not anti-Islamic to
be discourteous to Bangladesh posters because they are not Muslims,
Seebach showed a stunning lack of international culture

I do not like to have to constantly inventory Seebach's failings, but
he has a nasty tendency to excuse his own errors while calling into
question other people's competence and sanity.

The tirades against me are the result of communitarian hatred, where
the inadequate members of the community seek reassurance in the
proposition that no matter how deeply inadequate they feel they are
they at a minimum aren't like "Nilges".

This communitarian hatred is triggered by outdated human responses.
One is showing solidarity with another for no reason, out of the blue.
Many posters are amazed that I would defend Schildt because in the
corporate world, such behavior is nonexistent and/or frowned upon;
nobody stands up to management on behalf of another save (rarely) for
technical reasons, as if computers were so important that the only
people deserving of common decency are "skilled" programmers.

Another is speaking as the one to the many: in the corporate world,
it's often dangerous to discuss ideas since one might find one's
advocating the negation of a hidden "corporate direction".

But it's always safe to find an outlet for one's rage against the
machine by savaging another person.

My responses to Internet bullying have been constant since 1987,
because computer networks used as tools of the rich have created a
constant situation, in which bullying is useful in keeping people in
line. I have gotten results, including the cleanup of the Kathy Sierra
and Herb Schildt articles and a situation here at work.

The fundamental insanity is the collective belief in being "special"
individually owing to one's "knowledge" of the right sort of technical
arcana. Too many people, holding programming sinecures so structured
today as to ensure that they don't make a mess (such as Seebach's bug
finder pseudojob) demarcate a false community consisting of people
given respect and recognition because on the one hand, they know the
same arcana, and on the other hand, their competence and independence
is not such that they are, in the mythos, "prima donnas who don't
write code like normal people".

News flash. Everyone is entitled to respect and recognition. And,
indeed, I have called people Nazis and faggots, in cases where I
recognize someone subhuman clearly, and my initial gestures of respect
(such as sending email to Seebach requesting offline discussion) have
been treated without respect. Even in this context, I have been quick
to praise Kiki for doing well as in the case where he replied
courteously and accurately to Sandeep. But mutual respect and
recognition does not preclude self-defense...something the Mama's boy
will never understand.

One reason I got out of programming was the facile scorn of
programmers for people who they thought were not as smart as they. In
actuality programming exclusive of computer science is a nasty and
trivial skill of which no one should be proud.

In article <2f3510b4-9027-4b21-99da-5f495192a671@g39g2000pri.googlegroups.com>,
spinoza1111  <spinoza1111@yahoo.com> wrote:
> http://catless.ncl.ac.uk/Risks/26.06.html#subj12
> 
> This shall shortly also be on the Digest, to where people may respond
> to it. However, responses are competently moderated.

I'm mildly curious about whether anyone has attempted to respond and
what happened to the response if so.  I'm mildly tempted myself,
but only mildly.

I now question, however, any previous claims that posts to comp.risks
are checked for technical accuracy; if nothing else, the comment
about why "void main()" might be questionable strikes me as incomplete.

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

In article <6dd832ed-0af0-4bb5-aac6-ffa77f0754b0@c11g2000vbe.googlegroups.com>,
BruceS  <bruces42@hotmail.com> wrote:
> On May 25, 10:59 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> > On May 25, 11:51 pm, BruceS <bruce...@hotmail.com> wrote:
> >
> >
> >
> > > On May 24, 7:10 pm, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
> >
> > > > "spinoza1111" <spinoza1...@yahoo.com> wrote in message
> >
> > > >news:6bd6d2d2-b8cb-4c16-8a55-646a5a57b203@j12g2000pri.googlegroups.com...
> >
> > > > [snip usual festering effluvium]
> >
> > > > 'Round and 'round and 'round he goes
> > > > Backing Schildt is all he knows
> > > > Bye bye Nilges
> >
> > > > Spewing insults snide and vile
> > > > Interlaced with Marxist bile
> > > > Bye bye Nilges
> >
> > > > No one here attends to what you're saying
> > > > They just hear a small sad jackass braying
> > > > Can't get past your hate for C
> > > > Poor pathetic wannabe
> > > > Nilges, bye bye
> >
> > > You've done it now.  He's going to complain that (1) your work is
> > > derivative and therefore inferior to his; and (2) the derivation
> > > implies rampant racism on your part.  At first the source eluded me,
> > > right at the edge of memory, but then I remembered GIYF and had the
> > > obvious answer.  LQTM.
> >
> > That ain't my complaint
> > Although the work is inferior:
> > What doth it attaint
> > Is...it hath no metre.
> 
> It appears that you missed the reference that I noticed but had to
> look up.  It scans fine when you know what you're looking for.  GIYF.
> HTH.

Fortunately the other Bruce finally supplied a reference, so I'm
not left wondering!  I'm curious, though -- I tried Googling,
but in this instance GWNMF.  What search terms did you use?

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

In article <slrnhvqrui.la7.usenet-nospam@guild.seebs.net>,
Seebs  <usenet-nospam@seebs.net> wrote:
> On 2010-05-26, Keith Thompson <kst-u@mib.org> wrote:

[ snip ]

> Speaking of rhyme... How do you pronounce C if you have to read it for
> some reason?  Is "char" pronounced like the verb "char", the noun "car", or
> the verb "care"?  (I'm pretty close to "care", with just a hint of an h in
> there, because I pronounce it like the first syllable of "character".)
> 
> What are the names of the punctuation marks?  Are those "braces" or "squiggly
> brackets"?  Is it "open paren", "open parens", or "open parenthesis"?
> 

In my usage, the { and } are either "curly brackets [braces]"
or "squirrely brackets [braces]", depending on -- something.
(It was mostly the latter when I first learned C, coming as I
was from a background that was mostly FORTRAN and IBM assembler,
with a bit of Pascal for good(?) measure.  The way I remember it,
those braces looked pretty strange!)

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

Seebs wrote:
 
> What are the names of the punctuation marks?
> Are those "braces" or "squiggly brackets"? 

N869
       Index
       ( ) (parentheses punctuator), 6.7.5.3, 6.8.4, 6.8.5
       , (comma punctuator), 6.5.2, 6.7, 6.7.2.1, 6.7.2.2, 6.7.2.3,
       [ ] (brackets punctuator), 6.7.5.2, 6.7.8
       { } (braces punctuator), 6.7.2.2, 6.7.2.3, 6.7.8, 6.8.2


-- 
pete

On 2010-05-29, blmblm  myrealbox.com <blmblm@myrealbox.com> wrote:
> I now question, however, any previous claims that posts to comp.risks
> are checked for technical accuracy; if nothing else, the comment
> about why "void main()" might be questionable strikes me as incomplete.

I would imagine that the moderator assumed that people would recognize that
the substantive issue is "it is hard to be totally sure that information
about people on Wikipedia is accurate, so it could harm a reputation or
something", and that apart from that, it's a wall of text, why read it?

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On May 30, 4:58=A0am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <2f3510b4-9027-4b21-99da-5f495192a...@g39g2000pri.googlegroups=
..com>,
>
> spinoza1111 =A0<spinoza1...@yahoo.com> wrote:
> >http://catless.ncl.ac.uk/Risks/26.06.html#subj12
>
> > This shall shortly also be on the Digest, to where people may respond
> > to it. However, responses are competently moderated.
>
> I'm mildly curious about whether anyone has attempted to respond and
> what happened to the response if so. =A0I'm mildly tempted myself,
> but only mildly.
>
> I now question, however, any previous claims that posts to comp.risks
> are checked for technical accuracy; if nothing else, the comment
> about why "void main()" might be questionable strikes me as incomplete.

This is because your level of expertise hasn't gotten to the point
where you're able to identify important issues versus Trivial
Pursuits. This is connected to your level of English.

I did notice that below a certain level, in computer applications, my
verbal facility was a positive defect in that it created
misunderstandings; this is why I'm glad to be out of the field...and
teaching English, history and philosophy.

My experience commencing in the 1960s was that underfunded schools
failed to teach English but to continued to graduate students; we have
people here who seem proud to have earned Ds in English.

These failures expected to find middle class jobs in factories but the
Nixon administration started a Thirty Year's War of
deindustrialization and union busting, so many of them were redirected
into computer programming owing to a widespread misunderstanding
(which Dijkstra challenged) that verbal facility was optional in
programming.

Therefore I discovered that with significant exceptions (a supervisor
at Baxter-Travenol, Whit Diffie, Bob Gaskins, and my supervisor at
Princeton) I had to keep my verbal facility under wraps. People not
comfortable with complex sentence structure would get "offended" to
use a word from business which I find itself offensive, since it
actually names a generalized resentment having to do with
subordination, which is then "taken out" on targets of convenience.

Complex sentence structure, you see, violates the business-survival
law of one-dimensionality, in which ideally, we handle stress by
making cardinally ordered bullet points; Herbert Marcuse called this
thinking "one-dimensional".

However, artists realize that most real-life situations are n-
dimensional and in this case, it's literally impossible to sort things
in a simple list of priority. They also realize that this is used
primarily to oppress people, from academic rankings to the Holocaust.

For example, if you build a program as you should, out of small
functions, you actually have the choice as to which to develop...and
this choice, in my experience, bothers managers.

In the case of computer applications, I realized that the ordering
rule needed to be what mathematicians call a "partial ordering" that
generates what mathematicians call a tree, and (this is critical)
complex sentence structure (using indirect reported speech, wh-
clauses, parentheses and so on) can best explain a complex programming
situation. But this collided with the lack of preparation in English
of many programmers.

I also discovered, at a Chicago consulting firm founded by a
University of Chicago graduate, that a separate class of academic
washouts had been created by the defunding of university education;
these were people who had mastered advanced English in grad school,
but who failed to get jobs in their terminal degree, and wanted to
become Yup-assed managers and use the lower class for their own
purposes. Because ability to think at the higher level had been
privatized, they imposed a strange "sumptuary law" on written and
spoken discourse: if you simultaneously used post K-12 English BUT
retained an interest in actually programming, this was "disruptive".

My point about main() is simply that it's a trivial and nasty issue
with all the appearance of being devised to make C and Linux
programmers feel good about themselves even when they can't program,
as seems to be the case with Seebach. Not knowing complex English
makes one able to emotionally select what you like and ignore what you
don't like, and it turns your prose and thought into a series of
emotional signifiers...in which you can switch from inane technical
discussions to the worst kind of personal trashing with no moral
order.

I don't think you think much above this level. I think in the past you
may have, but working either for corporations or for corporation-
dominated universities forces people, in my experience, to self-
moronize and to simplify their speech and thought patterns to fit in.

For this reason, you're ready to trash Peter Neumann for accepting the
post. The problem being that he's accepted thirty posts from me over
time.

When people lose the ability to partially order and instead replace
partial ordering (with its implication that you retain some freedom of
choice) by one-dimensional thinking, they usually use personalities
and transitive axioms such as "Nilges is an asshole, therefore any one
who accepts him is an asshole" to flatten the tree of partial moral
ordering into the brutal, if time-saving, list of who's in and who's
out, to be used, ultimately, to load the train for Auschwitz.
>
> --
> B. L. Massingill
> ObDisclaimer: =A0I don't speak for my employers; they return the favor.

On May 30, 7:04=A0am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-05-29, blmblm =A0myrealbox.com <blm...@myrealbox.com> wrote:
>
> > I now question, however, any previous claims that posts to comp.risks
> > are checked for technical accuracy; if nothing else, the comment
> > about why "void main()" might be questionable strikes me as incomplete.
>
> I would imagine that the moderator assumed that people would recognize th=
at
> the substantive issue is "it is hard to be totally sure that information
> about people on Wikipedia is accurate, so it could harm a reputation or
> something", and that apart from that, it's a wall of text, why read it?


It's a wall of text, why read it
There's so many things better to do
All these weary words...all this shit
How dare he make such a to-do.

And so the Marines stood down while the Baghdad library burned.
And so, the UN stood down while the library in Sarajevo burned.
And so, the Romans stood down, while the library in Alexandria,
burned.

Where are the simple answers in all these books
Let us open them at random to find heresy.
Here Hypatia questions whether the earth is at the center
Obviously this is a mistake.

Hound her for fifteen years, strip her naked and kill her for these
errors.

The world is a wall of text destroy it
People are words. Kill them.



Peter, Neumann reads what's submitted and has the courage to get in
touch with the people who submit posts when he has questions. You
claim to moderate clcm but you don't read posts and you don't contact
submitters, because you're a pansy, basically. You do so to create the
fraudulent impression that you're an expert in C. You're not: no
expert would have submitted the code I've seen from you.



>
> -s
> --
> Copyright 2010, all wrongs reversed. =A0Peter Seebach / usenet-nos...@see=
bs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny picturesht=
tp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On May 30, 1:04=A0pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On May 30, 7:04=A0am, Seebs <usenet-nos...@seebs.net> wrote:
>
> > On 2010-05-29, blmblm =A0myrealbox.com <blm...@myrealbox.com> wrote:
>
> > > I now question, however, any previous claims that posts to comp.risks
> > > are checked for technical accuracy; if nothing else, the comment
> > > about why "void main()" might be questionable strikes me as incomplet=
e.
>
> > I would imagine that the moderator assumed that people would recognize =
that
> > the substantive issue is "it is hard to be totally sure that informatio=
n
> > about people on Wikipedia is accurate, so it could harm a reputation or
> > something", and that apart from that, it's a wall of text, why read it?
>
> It's a wall of text, why read it
> There's so many things better to do
> All these weary words...all this shit
> How dare he make such a to-do.
>
> And so the Marines stood down while the Baghdad library burned.
> And so, the UN stood down while the library in Sarajevo burned.
> And so, the Romans stood down, while the library in Alexandria,
> burned.
>
> Where are the simple answers in all these books
> Let us open them at random to find heresy.
> Here Hypatia questions whether the earth is at the center
> Obviously this is a mistake.
>
> Hound her for fifteen years, strip her naked and kill her for these
> errors.
>
> The world is a wall of text destroy it
> People are words. Kill them.
>
> Peter, Neumann reads what's submitted and has the courage to get in
> touch with the people who submit posts when he has questions. You
> claim to moderate clcm but you don't read posts and you don't contact
> submitters, because you're a pansy, basically. You do so to create the
> fraudulent impression that you're an expert in C. You're not: no
> expert would have submitted the code I've seen from you.
>
>
>
>
>
> > -s
> > --
> > Copyright 2010, all wrongs reversed. =A0Peter Seebach / usenet-nos...@s=
eebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictures=
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Update: in Risks 26.07, Peter apologizes for publishing my note. I
have asked him to retract the retraction, since I feel he has been
deluged with your spam, and needs to reconnect with the better angels
of his nature.

We all can become mob members. We become mob members when we forget
the grace notes...such as thinking "hey, maybe it isn't for me to
attack Schildt since I don't got no degree", or "hey, maybe I should
confab with Nilges before embarassing him on comp.risks".

And: I make no apology for my response to the lack of decency by
inviting people to get fucked. This is what happens when you start
treating silly programming languages as more important than people.

In article <0285af6a-9045-4bdb-943a-63df9c47b280@11g2000prv.googlegroups.com>,
spinoza1111  <spinoza1111@yahoo.com> wrote:
> On May 30, 4:58 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > In article <2f3510b4-9027-4b21-99da-5f495192a...@g39g2000pri.googlegroups.com>,
> >
> > spinoza1111  <spinoza1...@yahoo.com> wrote:
> > >http://catless.ncl.ac.uk/Risks/26.06.html#subj12
> >
> > > This shall shortly also be on the Digest, to where people may respond
> > > to it. However, responses are competently moderated.
> >
> > I'm mildly curious about whether anyone has attempted to respond and
> > what happened to the response if so.  I'm mildly tempted myself,
> > but only mildly.
> >
> > I now question, however, any previous claims that posts to comp.risks
> > are checked for technical accuracy; if nothing else, the comment
> > about why "void main()" might be questionable strikes me as incomplete.

[ snip ]

> In the case of computer applications, I realized that the ordering
> rule needed to be what mathematicians call a "partial ordering" that
> generates what mathematicians call a tree, 

I'd have said a directed acyclic graph rather than a tree, but --
there I go again, picking apart some detail, right?

> and (this is critical)
> complex sentence structure (using indirect reported speech, wh-
> clauses, parentheses and so on) can best explain a complex programming
> situation. But this collided with the lack of preparation in English
> of many programmers.

[ snip ]

> For this reason, you're ready to trash Peter Neumann for accepting the
> post. 

No.  There is, in my mind at least, quite a difference between
saying "I think a bit less of this person than I did before this
incident" and trashing him, and indeed, I'm not sure I'd even go as
far as saying the former in public -- I don't think I know enough
about the situation to slight him publicly.  The claim that all
posts are checked for accuracy -- that was *your* claim I had in
mind, though I admit I don't remember its exact wording, and yes,
I do think his accepting of your post casts some doubt on that.
I also am curious about whether he was aware when he accepted your
post of the discussions you've engaged in in other public venues.
I would stop well short, though, of claiming that any of this
casts doubt on his competence as a moderator.

> The problem being that he's accepted thirty posts from me over
> time.

"Fascinating"?  

I've been reading, or at least skimming, comp.risks for several
years, and generally I figure what I read there is credible, but
perhaps I should be reading more critically.  (It's also kind
of curious that I don't remember noticing any of your posts, 
given that I have a pretty good memory of your participation in
several Usenet newsgroups I follow, but -- <shrug>.  I guess 
if I'm really curious I can check the archives.)

[ snip ]

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

On Jun 1, 2:59=A0am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <0285af6a-9045-4bdb-943a-63df9c47b...@11g2000prv.googlegroups.=
com>,
>
>
>
>
>
> spinoza1111 =A0<spinoza1...@yahoo.com> wrote:
> > On May 30, 4:58 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > > In article <2f3510b4-9027-4b21-99da-5f495192a...@g39g2000pri.googlegr=
oups.com>,
>
> > > spinoza1111 =A0<spinoza1...@yahoo.com> wrote:
> > > >http://catless.ncl.ac.uk/Risks/26.06.html#subj12
>
> > > > This shall shortly also be on the Digest, to where people may respo=
nd
> > > > to it. However, responses are competently moderated.
>
> > > I'm mildly curious about whether anyone has attempted to respond and
> > > what happened to the response if so. =A0I'm mildly tempted myself,
> > > but only mildly.
>
> > > I now question, however, any previous claims that posts to comp.risks
> > > are checked for technical accuracy; if nothing else, the comment
> > > about why "void main()" might be questionable strikes me as incomplet=
e.
>
> [ snip ]
>
> > In the case of computer applications, I realized that the ordering
> > rule needed to be what mathematicians call a "partial ordering" that
> > generates what mathematicians call a tree,
>
> I'd have said a directed acyclic graph rather than a tree, but --
> there I go again, picking apart some detail, right?

No, you're just wrong. If the set is finite it's a tree. Furthermore,
I said it's a tree to clarify the definition, but you use language
less to come to common understanding (cf Habermas) than to create a
partial ordering and score points, right?

>
> > and (this is critical)
> > complex sentence structure (using indirect reported speech, wh-
> > clauses, parentheses and so on) can best explain a complex programming
> > situation. But this collided with the lack of preparation in English
> > of many programmers.
>
> [ snip ]
>
> > For this reason, you're ready to trash Peter Neumann for accepting the
> > post.
>
> No. =A0There is, in my mind at least, quite a difference between
> saying "I think a bit less of this person than I did before this
> incident" and trashing him, and indeed, I'm not sure I'd even go as
> far as saying the former in public -- I don't think I know enough
> about the situation to slight him publicly. =A0The claim that all
> posts are checked for accuracy -- that was *your* claim I had in
> mind, though I admit I don't remember its exact wording, and yes,
> I do think his accepting of your post casts some doubt on that.

He's accepted about 30 posts over the years, and agreed to be a source
for my book. However, I shouldn't have to play the game of describing
my (limited) association with prominent people such as Nash or
Neumann. If you people had common decency and used this ng for its
intended purpose, I would have no need. As it is, because I know far
more about computer science and am far more literate and broadly
educated, I am forced to continually establish credibility.

Neumann's cowardly retraction lowers HIM in MY view and that is what
counts.


> I also am curious about whether he was aware when he accepted your
> post of the discussions you've engaged in in other public venues.
> I would stop well short, though, of claiming that any of this
> casts doubt on his competence as a moderator.

The fact that I am a target for bullies is independent of the worth of
the post, unless you're an Israeli...or something like that (cf the
disgusting news about the attack on the Mavi Marmara). It could mean
that the "rough consensus" is right, or it could mean that the
"cybernetic mob" is wrong.



>
> > The problem being that he's accepted thirty posts from me over
> > time.
>
> "Fascinating"? =A0
>
> I've been reading, or at least skimming, comp.risks for several
> years, and generally I figure what I read there is credible, but
> perhaps I should be reading more critically. =A0(It's also kind
> of curious that I don't remember noticing any of your posts,
> given that I have a pretty good memory of your participation in
> several Usenet newsgroups I follow, but -- <shrug>. =A0I guess
> if I'm really curious I can check the archives.)

And so she goes, not with a bang but rather a whimper.
>
> [ snip ]
>
> --
> B. L. Massingill
> ObDisclaimer: =A0I don't speak for my employers; they return the favor.

spinoza1111 wrote:
) On Jun 1, 2:59?am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
)> spinoza1111 ?<spinoza1...@yahoo.com> wrote:
)> > In the case of computer applications, I realized that the ordering
)> > rule needed to be what mathematicians call a "partial ordering" that
)> > generates what mathematicians call a tree,
)>
)> I'd have said a directed acyclic graph rather than a tree, but --
)> there I go again, picking apart some detail, right?
)
) No, you're just wrong. If the set is finite it's a tree.

False, for two distinct reasons.
- There doesn't have to be a single root in a partial ordering.
- There can be multiple paths leading from one item to another.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

In article <1140a5a7-ff25-46c0-9554-b47a5f4bdfc4@11g2000prw.googlegroups.com>,
spinoza1111  <spinoza1111@yahoo.com> wrote:
> On Jun 1, 2:59 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > In article <0285af6a-9045-4bdb-943a-63df9c47b...@11g2000prv.googlegroups.com>,
> >
> >
> >
> >
> >
> > spinoza1111  <spinoza1...@yahoo.com> wrote:
> > > On May 30, 4:58 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > > > In article <2f3510b4-9027-4b21-99da-5f495192a...@g39g2000pri.googlegroups.com>,

[ snip ]

> > > In the case of computer applications, I realized that the ordering
> > > rule needed to be what mathematicians call a "partial ordering" that
> > > generates what mathematicians call a tree,
> >
> > I'd have said a directed acyclic graph rather than a tree, but --
> > there I go again, picking apart some detail, right?
> 
> No, you're just wrong. If the set is finite it's a tree. 

We must be using different definitions of at least one of the relevant
terms.  According to what I was taught (and indeed what I teach):

A partial ordering is a binary relation (call it LE) that is
reflexive (a LE a), symmetric (if a LE b and b LE a, then a =
b), and transitive (if a LE b and b LE c, then a LE c).  A binary
relation in turn is simply a set of ordered pairs of elements of
the underlying set.  If the set is finite, one could represent
the relation in the form of a directed graph.  The transitivity
and symmetry properties preclude there being cycles in the graph
(aside from the trivial ones defined by the pairs required for
reflexivity).  But I'm not thinking of anything in this definition
that implies a tree structure (maximum of one incoming edge per
node).  ?  

As an example of what I have in mind, consider a set with elements
a, b1, b2, and c, with a binary relation LE defined by the set of
pairs (a, a), (b1, b1), (b2, b2), (c, c), (a, b1), (a, b2), (b1, c),
(b2, c), (a, c).  A pictorial representation of this would be a
diamond shape.

(I notice that while I was composing this post Willem posted 
something that seems to agree with my definitions.)

> Furthermore,
> I said it's a tree to clarify the definition, but you use language
> less to come to common understanding (cf Habermas) than to create a
> partial ordering and score points, right?

Yes and no.  I *am* a pedantic nitpicker, true, but as for whether
I put that to use only to try to score points -- no, I don't think
so, though there certainly *are* situations that seem to tempt me 
to try to score points, bad idea though I know that to be.

> > > and (this is critical)
> > > complex sentence structure (using indirect reported speech, wh-
> > > clauses, parentheses and so on) can best explain a complex programming
> > > situation. But this collided with the lack of preparation in English
> > > of many programmers.

[ snip ]

> > I've been reading, or at least skimming, comp.risks for several
> > years, and generally I figure what I read there is credible, but
> > perhaps I should be reading more critically.  (It's also kind
> > of curious that I don't remember noticing any of your posts,
> > given that I have a pretty good memory of your participation in
> > several Usenet newsgroups I follow, but -- <shrug>.  I guess
> > if I'm really curious I can check the archives.)
> 
> And so she goes, not with a bang but rather a whimper.

"Whimper"?  Whatever.

(I *was* curious, and I find that the history goes back to .... 1988.
Good heavens.  Some familiar themes, though, in those early posts.)

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

On May 29, 3:00=A0pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <6dd832ed-0af0-4bb5-aac6-ffa77f075...@c11g2000vbe.googlegroups=
..com>,
>
>
>
> BruceS =A0<bruce...@hotmail.com> wrote:
> > On May 25, 10:59 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> > > On May 25, 11:51 pm, BruceS <bruce...@hotmail.com> wrote:
>
> > > > On May 24, 7:10 pm, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote=
:
>
> > > > > "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> > > > >news:6bd6d2d2-b8cb-4c16-8a55-646a5a57b203@j12g2000pri.googlegroups=
..com...
>
> > > > > [snip usual festering effluvium]
>
> > > > > 'Round and 'round and 'round he goes
> > > > > Backing Schildt is all he knows
> > > > > Bye bye Nilges
>
> > > > > Spewing insults snide and vile
> > > > > Interlaced with Marxist bile
> > > > > Bye bye Nilges
>
> > > > > No one here attends to what you're saying
> > > > > They just hear a small sad jackass braying
> > > > > Can't get past your hate for C
> > > > > Poor pathetic wannabe
> > > > > Nilges, bye bye
>
> > > > You've done it now. =A0He's going to complain that (1) your work is
> > > > derivative and therefore inferior to his; and (2) the derivation
> > > > implies rampant racism on your part. =A0At first the source eluded =
me,
> > > > right at the edge of memory, but then I remembered GIYF and had the
> > > > obvious answer. =A0LQTM.
>
> > > That ain't my complaint
> > > Although the work is inferior:
> > > What doth it attaint
> > > Is...it hath no metre.
>
> > It appears that you missed the reference that I noticed but had to
> > look up. =A0It scans fine when you know what you're looking for. =A0GIY=
F.
> > HTH.
>
> Fortunately the other Bruce finally supplied a reference, so I'm
> not left wondering! =A0I'm curious, though -- I tried Googling,
> but in this instance GWNMF. =A0What search terms did you use?

I started with "song bye", and Google did its nice little auto-fill
bit, then I just followed the first suggested search to confirm.

blmblm@myrealbox.com <blmblm@myrealbox.com> writes:
> spinoza1111  <spinoza1111@yahoo.com> wrote:

Why are you wasting our time arguing with this moron?

>> On Jun 1, 2:59 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
>> > In article <0285af6a-9045-4bdb-943a-63df9c47b...@11g2000prv.googlegroups.com>,
>> >
>> > spinoza1111  <spinoza1...@yahoo.com> wrote:
>> > > On May 30, 4:58 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
>> > > > In article <2f3510b4-9027-4b21-99da-5f495192a...@g39g2000pri.googlegroups.com>,
>
> [ snip ]
>
>> > > In the case of computer applications, I realized that the ordering
>> > > rule needed to be what mathematicians call a "partial ordering" that
>> > > generates what mathematicians call a tree,
>> >
>> > I'd have said a directed acyclic graph rather than a tree, but --
>> > there I go again, picking apart some detail, right?
>> 
>> No, you're just wrong. If the set is finite it's a tree. 
>
> We must be using different definitions of at least one of the relevant
> terms.  According to what I was taught (and indeed what I teach):
>
> A partial ordering is a binary relation (call it LE) that is
> reflexive (a LE a), symmetric (if a LE b and b LE a, then a =
> b), and transitive (if a LE b and b LE c, then a LE c). 

For values of 'symmetric' equal to 'antisymmetric'.

For a DAG you clearly want an irreflexive partial order.
But if you're the bilgemeister and want a tree, then your
best bet is a lobotomy, or frequent disappointment.

Phil
-- 
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

In article <87k4qio1a8.fsf@kilospaz.fatphil.org>,
Phil Carmody  <thefatphil_demunged@yahoo.co.uk> wrote:
> blmblm@myrealbox.com <blmblm@myrealbox.com> writes:
> > spinoza1111  <spinoza1111@yahoo.com> wrote:
> 
> Why are you wasting our time arguing with this moron?

Good question, and one for which I don't have a good answer, except
that it seemed like a good idea at the time.  <shrug>

> >> On Jun 1, 2:59 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> >> > In article
> <0285af6a-9045-4bdb-943a-63df9c47b...@11g2000prv.googlegroups.com>,
> >> >
> >> > spinoza1111  <spinoza1...@yahoo.com> wrote:
> >> > > On May 30, 4:58 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> >> > > > In article
> <2f3510b4-9027-4b21-99da-5f495192a...@g39g2000pri.googlegroups.com>,
> >
> > [ snip ]
> >
> >> > > In the case of computer applications, I realized that the ordering
> >> > > rule needed to be what mathematicians call a "partial ordering" that
> >> > > generates what mathematicians call a tree,
> >> >
> >> > I'd have said a directed acyclic graph rather than a tree, but --
> >> > there I go again, picking apart some detail, right?
> >> 
> >> No, you're just wrong. If the set is finite it's a tree. 
> >
> > We must be using different definitions of at least one of the relevant
> > terms.  According to what I was taught (and indeed what I teach):
> >
> > A partial ordering is a binary relation (call it LE) that is
> > reflexive (a LE a), symmetric (if a LE b and b LE a, then a =
> > b), and transitive (if a LE b and b LE c, then a LE c). 
> 
> For values of 'symmetric' equal to 'antisymmetric'.

Indeed.  I even looked up the definition to remind myself what
the names of the various properties were, and yet somehow I *still*
got the names wrong.  Sigh.

> For a DAG you clearly want an irreflexive partial order.

Now that you mention it -- yes, since reflexivity means you have
an edge from each node back to itself?

> But if you're the bilgemeister and want a tree, then your
> best bet is a lobotomy, or frequent disappointment.
> Phil
> -- 
> I find the easiest thing to do is to k/f myself and just troll away
> -- David Melville on r.a.s.f1

I've never been quite sure what your quote here means, but it *might*
apply, and might even sort of answer your "why are you doing this?"
question earlier.

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

In article <a18b105b-bdb4-44ee-aa19-5309f0c0b482@b21g2000vbh.googlegroups.com>,
BruceS  <bruces42@hotmail.com> wrote:
> On May 29, 3:00 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > In article <6dd832ed-0af0-4bb5-aac6-ffa77f075...@c11g2000vbe.googlegroups.com>,
> >
> >
> >
> > BruceS  <bruce...@hotmail.com> wrote:
> > > On May 25, 10:59 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> > > > On May 25, 11:51 pm, BruceS <bruce...@hotmail.com> wrote:
> >
> > > > > On May 24, 7:10 pm, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:
> >
> > > > > > "spinoza1111" <spinoza1...@yahoo.com> wrote in message
> >
> > > > > >news:6bd6d2d2-b8cb-4c16-8a55-646a5a57b203@j12g2000pri.googlegroups.com...
> >
> > > > > > [snip usual festering effluvium]
> >
> > > > > > 'Round and 'round and 'round he goes
> > > > > > Backing Schildt is all he knows
> > > > > > Bye bye Nilges
> >
> > > > > > Spewing insults snide and vile
> > > > > > Interlaced with Marxist bile
> > > > > > Bye bye Nilges
> >
> > > > > > No one here attends to what you're saying
> > > > > > They just hear a small sad jackass braying
> > > > > > Can't get past your hate for C
> > > > > > Poor pathetic wannabe
> > > > > > Nilges, bye bye

[ snip ]

> > > It appears that you missed the reference that I noticed but had to
> > > look up.  It scans fine when you know what you're looking for.  GIYF.
> > > HTH.
> >
> > Fortunately the other Bruce finally supplied a reference, so I'm
> > not left wondering!  I'm curious, though -- I tried Googling,
> > but in this instance GWNMF.  What search terms did you use?
> 
> I started with "song bye", and Google did its nice little auto-fill
> bit, then I just followed the first suggested search to confirm.

Hm!  I just tried typing the same words into Google's search box,
and I got a different result -- first, no magic auto-fill stuff,
and then when I just pressed "enter" for a list of hits, nothing
on the first pageful seems like it would take me to the actual
song being parodied(?).

If I didn't already have too many things on my "I wish I knew
more about this" queue, I'd add to it some questions about what
exactly, or even approximately, Google is doing with the words
one types into its search box, because sometimes the results do
*not* make sense to me.  !

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

blmblm@myrealbox.com <blmblm@myrealbox.com> writes:

> In article <87k4qio1a8.fsf@kilospaz.fatphil.org>,
> Phil Carmody  <thefatphil_demunged@yahoo.co.uk> wrote:
>> blmblm@myrealbox.com <blmblm@myrealbox.com> writes:
>> > spinoza1111  <spinoza1111@yahoo.com> wrote:
>> 
>> Why are you wasting our time arguing with this moron?
>
> Good question, and one for which I don't have a good answer, except
> that it seemed like a good idea at the time.  <shrug>

Have you considered the possibility that the technical errors are there
to get a rise from people who won't respond to the insults?  Can anyone
be that wrong that often?

<snip>
>> > A partial ordering is a binary relation (call it LE) that is
>> > reflexive (a LE a), [anti]symmetric (if a LE b and b LE a, then a =
>> > b), and transitive (if a LE b and b LE c, then a LE c). 
[Phil's correction edited in]

>> For a DAG you clearly want an irreflexive partial order.
>
> Now that you mention it -- yes, since reflexivity means you have
> an edge from each node back to itself?

Yes, and antisymmetry must go as well.

For every partial order LE, there is a corresponding "strict partial
order", L, that is irreflexive (not(aLEb)) and transitive.  As a result
it is asymmetric (if aLb then not(bLa)) rather than antisymmetric.

The terminology is odd (hence the scare quotes) because a "strict
partial order" is not a partial order by the usual definition.  However,
because of the 1-1 correspondence between them, there is a natural DAG
induced by every partial order -- it's that DAG that represents the
strict version of original order.

Just to be clear: not a tree. 

<snip>
-- 
Ben.

Ben Bacarisse wrote:

<snip>

> Have you considered the possibility that the technical errors are there
> to get a rise from people who won't respond to the insults?

Hanlon's Razor.

> Can anyone be that wrong that often?

Apparently, yes.

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

On Jun 2, 2:22=A0am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <a18b105b-bdb4-44ee-aa19-5309f0c0b...@b21g2000vbh.googlegroups=
..com>,
>
>
>
> BruceS =A0<bruce...@hotmail.com> wrote:
> > On May 29, 3:00 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > > In article <6dd832ed-0af0-4bb5-aac6-ffa77f075...@c11g2000vbe.googlegr=
oups.com>,
>
> > > BruceS =A0<bruce...@hotmail.com> wrote:
> > > > On May 25, 10:59 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> > > > > On May 25, 11:51 pm, BruceS <bruce...@hotmail.com> wrote:
>
> > > > > > On May 24, 7:10 pm, "Bruce C. Baker" <gone_pe...@nowhere.net> w=
rote:
>
> > > > > > > "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> > > > > > >news:6bd6d2d2-b8cb-4c16-8a55-646a5a57b203@j12g2000pri.googlegr=
oups.com...
>
> > > > > > > [snip usual festering effluvium]
>
> > > > > > > 'Round and 'round and 'round he goes
> > > > > > > Backing Schildt is all he knows
> > > > > > > Bye bye Nilges
>
> > > > > > > Spewing insults snide and vile
> > > > > > > Interlaced with Marxist bile
> > > > > > > Bye bye Nilges
>
> > > > > > > No one here attends to what you're saying
> > > > > > > They just hear a small sad jackass braying
> > > > > > > Can't get past your hate for C
> > > > > > > Poor pathetic wannabe
> > > > > > > Nilges, bye bye
>
> [ snip ]
>
> > > > It appears that you missed the reference that I noticed but had to
> > > > look up. =A0It scans fine when you know what you're looking for. =
=A0GIYF.
> > > > HTH.
>
> > > Fortunately the other Bruce finally supplied a reference, so I'm
> > > not left wondering! =A0I'm curious, though -- I tried Googling,
> > > but in this instance GWNMF. =A0What search terms did you use?
>
> > I started with "song bye", and Google did its nice little auto-fill
> > bit, then I just followed the first suggested search to confirm.
>
> Hm! =A0I just tried typing the same words into Google's search box,
> and I got a different result -- first, no magic auto-fill stuff,
> and then when I just pressed "enter" for a list of hits, nothing
> on the first pageful seems like it would take me to the actual
> song being parodied(?).

Interesting.  I'd expect Google to do the same thing no matter who
typed in the query, and to not change significantly for something like
this over the course of a day or two.  I just tried it again with the
same results, from both Firefox and IE.  Are you just using a Google
toolbar, or something like that, or are you actually going to www.google.co=
m
and typing into the entry field there?

On 2010-06-02, Richard Heathfield <rjh@see.sig.invalid> wrote:
> Ben Bacarisse wrote:
><snip>

>> Have you considered the possibility that the technical errors are there
>> to get a rise from people who won't respond to the insults?

> Hanlon's Razor.

I have considered that, but... There is a Father Brown mystery in which
he points out that someone MUST have known the truth in order to get every
single detail of something wrong.

Nilges does indeed approach that level of consistent error.  However,
I think it may still be possible to provide an alternative theory that
explains this more as incompetence than malice, although arguably still
"malice" in a broader sense.  If we consider the plausible notion that
he's got some severe pathological narcissism going, his errors can be
explained much more simply.  It's obvious he knows very little about any
of the subjects on which we've seen him talk; however, it's also obvious
that he reflexively opposes people he dislikes at all times.  If you view
his statements, not as claims about the actual facts under discussion,
but as assertions that the people he's disagreeing with are Bad People,
everything makes sense.  He picked variable names in a reasonably
unexceptional way until I pointed out that he was doing something stupid;
after that he went out of his way to name them extremely badly, in a kind
of over-the-top satire/parody of "Hungarian".

Which is to say -- it's not consciously intended as incorrect, but it is
not mere coincidence that he's wrong so often.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

In article <58057b10-b90e-4c74-9aea-dfe8258c770f@c13g2000vbr.googlegroups.com>,
BruceS  <bruces42@hotmail.com> wrote:
> On Jun 2, 2:22 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > In article <a18b105b-bdb4-44ee-aa19-5309f0c0b...@b21g2000vbh.googlegroups.com>,
> >
> >
> >
> > BruceS  <bruce...@hotmail.com> wrote:
> > > On May 29, 3:00 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > > > In article <6dd832ed-0af0-4bb5-aac6-ffa77f075...@c11g2000vbe.googlegroups.com>,
> >
> > > > BruceS  <bruce...@hotmail.com> wrote:
> > > > > On May 25, 10:59 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> > > > > > On May 25, 11:51 pm, BruceS <bruce...@hotmail.com> wrote:
> >
> > > > > > > On May 24, 7:10 pm, "Bruce C. Baker" <gone_pe...@nowhere.net> wrote:

[ snip ]

> > > > > > > > 'Round and 'round and 'round he goes
> > > > > > > > Backing Schildt is all he knows
> > > > > > > > Bye bye Nilges

[ snip ]

> > > > > It appears that you missed the reference that I noticed but had to
> > > > > look up.  It scans fine when you know what you're looking for.  GIYF.
> > > > > HTH.
> >
> > > > Fortunately the other Bruce finally supplied a reference, so I'm
> > > > not left wondering!  I'm curious, though -- I tried Googling,
> > > > but in this instance GWNMF.  What search terms did you use?
> >
> > > I started with "song bye", and Google did its nice little auto-fill
> > > bit, then I just followed the first suggested search to confirm.
> >
> > Hm!  I just tried typing the same words into Google's search box,
> > and I got a different result -- first, no magic auto-fill stuff,
> > and then when I just pressed "enter" for a list of hits, nothing
> > on the first pageful seems like it would take me to the actual
> > song being parodied(?).
> 
> Interesting.  I'd expect Google to do the same thing no matter who
> typed in the query, and to not change significantly for something like
> this over the course of a day or two.  I just tried it again with the
> same results, from both Firefox and IE.  Are you just using a Google
> toolbar, or something like that, or are you actually going to www.google.com
> and typing into the entry field there?

The latter, using Firefox -- but a rather old version.

Trying again, with a more-up-to-date version, I get the same behavior
you did.  

Hm!  but at least this makes a kind of sense.

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

Seebs wrote:
> On 2010-06-02, Richard Heathfield <rjh@see.sig.invalid> wrote:
>> Ben Bacarisse wrote:
>> <snip>
> 
>>> Have you considered the possibility that the technical errors are there
>>> to get a rise from people who won't respond to the insults?
> 
>> Hanlon's Razor.
> 
> I have considered that, but... There is a Father Brown mystery in which
> he points out that someone MUST have known the truth in order to get every
> single detail of something wrong.

I thought I'd read them all, but I must have missed that one. Good! (I 
look forward to it.) But of course it is based on a false premise. Not 
even EGN gets /everything/ wrong (just as the Mandelbrot Set's 
beetle-like convolutions do not cover the /entire/ plane). For example, 
it is sometimes possible to compile the code he submits without first 
hacking it into shape.

<snip>

> He picked variable names in a reasonably
> unexceptional way until I pointed out that he was doing something stupid;
> after that he went out of his way to name them extremely badly, in a kind
> of over-the-top satire/parody of "Hungarian".

Sorry to disagree, but he's been using that style for years. Here is an 
example of Nilges code from 2002:

      {
          if ( intStringDelimiter )
              { intIndex2 = (int)strstr(strInstring + intIndex1,
  strDelimiter)
                            -
                            (int)strInstring; }
          else {
              intIndex1 = strspn(strInstring + intIndex1, strDelimiter)
  + intIndex1;
              if ( intIndex1 <= strlen(strInstring) )
                  intIndex2 = strcspn(strInstring + intIndex1,
  strDelimiter) + intIndex1;
                  else intIndex2 = intIndex1;
          }
          if ( ++intCount == intIndex ) break;
          intIndex1 = intIndex2 +
  (intStringDelimiter?strlen(strDelimiter):1);
      }

(And yes, it really was indented like that.)

> 
> Which is to say -- it's not consciously intended as incorrect, but it is
> not mere coincidence that he's wrong so often.

No, it's not coincidence. The guy's simply incompetent on a massive 
scale, and shows no disposition whatsoever towards learning. *That's* 
why he's wrong so often.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

blmblm@myrealbox.com <blmblm@myrealbox.com> wrote:

> spinoza1111  <spinoza1111@yahoo.com> wrote:
> > And so she goes, not with a bang but rather a whimper.
> 
> "Whimper"?  Whatever.
> 
> (I *was* curious, and I find that the history goes back to .... 1988.
> Good heavens.  Some familiar themes, though, in those early posts.)

1925, ITYF. But the "rather" spoils it rather.

Richard

In article <4c0f6b27.1194156@news.xs4all.nl>,
Richard Bos <rlbos@xs4all.nl> wrote:
> blmblm@myrealbox.com <blmblm@myrealbox.com> wrote:
> 
> > spinoza1111  <spinoza1111@yahoo.com> wrote:
> > > And so she goes, not with a bang but rather a whimper.
> > 
> > "Whimper"?  Whatever.
> > 
> > (I *was* curious, and I find that the history goes back to .... 1988.
> > Good heavens.  Some familiar themes, though, in those early posts.)
> 
> 1925, ITYF. 

Say what?  The history I'm talking about is the history of Nilges posts
to comp.risks.  What history are you talking about?

> But the "rather" spoils it rather.

Oh, maybe you mean the phrase that's being paraphrased rather
than quoted ....  Yes, okay, after Googling for the original, that
seems like a good guess.

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

David Thompson <dave.thompson2@verizon.net> writes:

> On Mon, 10 May 2010 11:56:29 -0700 (PDT), John Bode
> <jfbode1029@gmail.com> wrote:
> <snip most 'spinoza' related material>
>> There is an agreed-upon definition of how the language is *supposed*
>> to work; that is the language standard.  Most implementations conform
>> closely to this standard, some moreso than others.  There is some slop
>> around the edges due to limitations in the implementation environment
>> or mistakes on the part of the implementor, but on the whole a
>> conforming compiler *should* accept a conforming program and reject a
>> non-conforming program.
>> 
> Not quite. First, a nit: the term 'conforming program' is defined by
> the standard in a way that is useless, knowingly so, and 'strictly
> conforming' is almost as bad.

I can't agree with this assessment.  These two terms are defined
as they are to help the Standard make statements about certain
classes of programs.  They may not serve the purpose you desire,
but that doesn't make them useless;  they are useful for the
purpose that (I believe) the Standard expects for them.

> We've had several tries seeking a term
> for the (useful!) category of programs that portably work correctly,
> and the least bad IMO was 'clc-compliant'.

The term 'clc-compliant' seems reasonable, or at least plausible,
but as a definition this statement falls short.  Unless there
is some sort of definition of what it means to "work correctly",
it says nothing.

> More substantively: modulo bugs a conforming implementation should
> accept *and correctly execute* a clc-compliant program *unless it's
> too big* -- and then as Quality of Implementation it should give an
> appropriate diagnostic, although the standard doesn't require it.

This statement is circular:  a clc-compliant program is one that
portably works correctly, and conforming implementations must
correctly execute a clc-compliant program.  Obviously this must
be true, otherwise the program in question is not 'clc-compliant',
by definition.

> On the other side, it must diagnose any program with a syntax error or
> constraint violation, but it is permitted to try to 'fix' such program
> into a valid and if lucky desired one.

Which is exactly the case under the existing Standard (absent
a #error directive).

> And it can have extensions that
> users intend and want, but mandate diagnosis in conforming mode. 

This statement appears to be discussing changing the definition
of the term "conforming implementation" in the Standard.  If so
then it is circularly self-contradictory -- it mandates diagnosis
for conditions that, by definition, the Standard does not
require diagnosing.


> And it *may* diagnose other errors, but in general there are many
> errors that are not practical to detect and thus cannot be rejected.
>
> IOW I agree with 'accept' mostly but 'reject' mostly not

I don't disagree with what I read as the spirit of the quoted
comments.  However, if there is some sort of objection to how these
terms are defined (and therefore what constitutes a "conforming
implementation"), I think the objectors should try writing a
complete replacement for section 4, "Conformance" (it's only eight
paragraphs).  If criticism is going to be offered, don't do it from
the sidelines, get out there on the playing field.  Don't want to
get out on the playing field?  Then be prepared for someone to
say "put up or shut up".

On Thu, 17 Jun 2010 12:31:40 -0700, Tim Rentsch
<txr@alumni.caltech.edu> wrote:

> David Thompson <dave.thompson2@verizon.net> writes:
> 
> > On Mon, 10 May 2010 11:56:29 -0700 (PDT), John Bode
> > <jfbode1029@gmail.com> wrote:
> > <snip most 'spinoza' related material>
> >> There is an agreed-upon definition of how the language is *supposed*
> >> to work; that is the language standard.  Most implementations conform
> >> closely to this standard, some moreso than others.  There is some slop
> >> around the edges due to limitations in the implementation environment
> >> or mistakes on the part of the implementor, but on the whole a
> >> conforming compiler *should* accept a conforming program and reject a
> >> non-conforming program.
> >> 
> > Not quite. First, a nit: the term 'conforming program' is defined by
> > the standard in a way that is useless, knowingly so, and 'strictly
> > conforming' is almost as bad.
> 
> I can't agree with this assessment.  These two terms are defined
> as they are to help the Standard make statements about certain
> classes of programs.  They may not serve the purpose you desire,
> but that doesn't make them useless;  they are useful for the
> purpose that (I believe) the Standard expects for them.
> 
'conforming' was a bodge to get C89 adopted; I strongly agree that
benefit justifies its infinitesimal cost, but as a class of programs
it's all strings over the alphabet, and I see no use for that. 
s-c was a serious attempt, but I find it unuseful. In particular for
the purpose here, deciding a set of programs that all implementations
of interest 'should' accept; in practice 99.99% of programs I want to
*and do* compile and especially port are not s-c. 'Of interest' to me
is definitely limited to hosted since programs that rely on embedded I
don't expect to be portable (although parts may, and often should);
and I might be willing to exclude one or two really weird outliers -- 
I haven't hit any yet, but I don't rule out the possibility.

(As a concrete example, I was recently looking at an area in OpenSSL
littered with #if's to make some filename handling differ on VMS. It
depends majorly on impl-def characteristics of fopen() -- but in a way
I believe makes sense to users on both VMS and non-VMS systems.) 

> > We've had several tries seeking a term
> > for the (useful!) category of programs that portably work correctly,
> > and the least bad IMO was 'clc-compliant'.
> 
> The term 'clc-compliant' seems reasonable, or at least plausible,
> but as a definition this statement falls short.  Unless there
> is some sort of definition of what it means to "work correctly",
> it says nothing.
> 
That is the hard part. My rough version is that a program works
correctly on some implementation if (each run of) it either produces
results consistent with (within the range specified by) a reasonable
understanding (mediated by discussion here if necessary) of the
standard (C plus others applicable like POSIX), or gives a clear
indication it has failed (either at translation or execution).

Preferably that 'result within standard' should also be within the
spec for the program, and that in turn consistent with the needs of
the user(s), but those are out of scope for the language. 

> > More substantively: modulo bugs a conforming implementation should
> > accept *and correctly execute* a clc-compliant program *unless it's
> > too big* -- and then as Quality of Implementation it should give an
> > appropriate diagnostic, although the standard doesn't require it.
> 
> This statement is circular:  a clc-compliant program is one that
> portably works correctly, and conforming implementations must
> correctly execute a clc-compliant program.  Obviously this must
> be true, otherwise the program in question is not 'clc-compliant',
> by definition.
> 
It's not circular, it's just vague; if I reasonably expect it to work,
implementations should make it work unless they can't.

> > On the other side, it must diagnose any program with a syntax error or
> > constraint violation, but it is permitted to try to 'fix' such program
> > into a valid and if lucky desired one.
> 
> Which is exactly the case under the existing Standard (absent
> a #error directive).
> 
> > And it can have extensions that
> > users intend and want, but mandate diagnosis in conforming mode. 
> 
> This statement appears to be discussing changing the definition
> of the term "conforming implementation" in the Standard.  If so
> then it is circularly self-contradictory -- it mandates diagnosis
> for conditions that, by definition, the Standard does not
> require diagnosing.
> 
Other way; if a program uses an extension that violates standard
syntax or constraints -- as practically all do, and that's a working
definition of 'extension' as opposed to 'implementation choice' --
then a conforming implementation must (required by standard) diagnose,
but may (by standard) then do anything, and should (IMO) accept using
its definition of the extension.

Formally this is the same as the prior point -- after diagnosis the
compiler tries to DWIM. But for an extension it can have very high
confidence about WIM, not just a guess.

> 
> > And it *may* diagnose other errors, but in general there are many
> > errors that are not practical to detect and thus cannot be rejected.
> >
> > IOW I agree with 'accept' mostly but 'reject' mostly not
> 
> I don't disagree with what I read as the spirit of the quoted
> comments.  However, if there is some sort of objection to how these
> terms are defined (and therefore what constitutes a "conforming
> implementation"), I think the objectors should try writing a
> complete replacement for section 4, "Conformance" (it's only eight
> paragraphs).  If criticism is going to be offered, don't do it from
> the sidelines, get out there on the playing field.  Don't want to
> get out on the playing field?  Then be prepared for someone to
> say "put up or shut up".

I certainly don't have a better solution. I haven't seen a language
conformance spec that could be accurately enforced except Ada, 
and that only because for a while it had the US Defense Department
spending loads of money on it, and it was done from scratch, and even
so AIUI there were still serious disagreements on some (small) points.
And it took quite a few years before people could use it. (And
relatively few did or do, although I don't believe that's caused by
the conformance spec, and personally I even like the language.)

But to define what I consider 'decent' or 'satisfactory', and can
reasonably argue others should also, I think my method works.

David Thompson wrote:

> We've had several tries seeking a term
> for the (useful!) category of programs that portably work correctly,
> and the least bad IMO was 'clc-compliant'.

I like "correct program".

ISO/IEC 9899:1999 (E)

4. Conformance

3 A program that is correct in all other aspects, 
  operating on correct data, containing unspecified behavior 
  shall be a 
  correct program 
  and act in accordance with 5.1.2.3.

-- 
pete

pete <pfiland@mindspring.com> writes:

> David Thompson wrote:
>
>> We've had several tries seeking a term
>> for the (useful!) category of programs that portably work correctly,
>> and the least bad IMO was 'clc-compliant'.
>
> I like "correct program".
>
> ISO/IEC 9899:1999 (E)
>
> 4. Conformance
>
> 3 A program that is correct in all other aspects, 
>   operating on correct data, containing unspecified behavior 
>   shall be a 
>   correct program 
>   and act in accordance with 5.1.2.3.

Unfortunately whether a program is a 'correct program' in the
sense of 4p3 depends on what implementation it's running on.
That isn't much help if we're trying to identify a set of
programs that are portably correct.  Hmmm, how about "portably
correct"?

David Thompson <dave.thompson2@verizon.net> writes:

> On Thu, 17 Jun 2010 12:31:40 -0700, Tim Rentsch
> <txr@alumni.caltech.edu> wrote:
>
>> David Thompson <dave.thompson2@verizon.net> writes:
>> 
>> > On Mon, 10 May 2010 11:56:29 -0700 (PDT), John Bode
>> > <jfbode1029@gmail.com> wrote:
>> > <snip most 'spinoza' related material>
>> >> There is an agreed-upon definition of how the language is *supposed*
>> >> to work; that is the language standard.  Most implementations conform
>> >> closely to this standard, some moreso than others.  There is some slop
>> >> around the edges due to limitations in the implementation environment
>> >> or mistakes on the part of the implementor, but on the whole a
>> >> conforming compiler *should* accept a conforming program and reject a
>> >> non-conforming program.
>> >> 
>> > Not quite. First, a nit: the term 'conforming program' is defined by
>> > the standard in a way that is useless, knowingly so, and 'strictly
>> > conforming' is almost as bad.
>> 
>> I can't agree with this assessment.  These two terms are defined
>> as they are to help the Standard make statements about certain
>> classes of programs.  They may not serve the purpose you desire,
>> but that doesn't make them useless;  they are useful for the
>> purpose that (I believe) the Standard expects for them.
>> 
> 'conforming' was a bodge to get C89 adopted; I strongly agree that
> benefit justifies its infinitesimal cost, but as a class of programs
> it's all strings over the alphabet, and I see no use for that. 
> s-c was a serious attempt, but I find it unuseful. In particular for
> the purpose here, deciding a set of programs that all implementations
> of interest 'should' accept; in practice 99.99% of programs I want to
> *and do* compile and especially port are not s-c. 'Of interest' to me
> is definitely limited to hosted since programs that rely on embedded I
> don't expect to be portable (although parts may, and often should);
> and I might be willing to exclude one or two really weird outliers -- 
> I haven't hit any yet, but I don't rule out the possibility.
>
> (As a concrete example, I was recently looking at an area in OpenSSL
> littered with #if's to make some filename handling differ on VMS. It
> depends majorly on impl-def characteristics of fopen() -- but in a way
> I believe makes sense to users on both VMS and non-VMS systems.) 

It still sounds like you're just saying that the terms the
Standard uses don't meet your needs.  I get that they don't
meet your needs, but that doesn't make them useless.


>> > We've had several tries seeking a term
>> > for the (useful!) category of programs that portably work correctly,
>> > and the least bad IMO was 'clc-compliant'.
>> 
>> The term 'clc-compliant' seems reasonable, or at least plausible,
>> but as a definition this statement falls short.  Unless there
>> is some sort of definition of what it means to "work correctly",
>> it says nothing.
>> 
> That is the hard part. My rough version is that a program works
> correctly on some implementation if (each run of) it either produces
> results consistent with (within the range specified by) a reasonable
> understanding (mediated by discussion here if necessary) of the
> standard

So...  you want a term for a program that portably works
correctly, but you only require the program to run correctly
on one implementation?  Where's the "portable" part?

> (C plus others applicable like POSIX), or gives a clear
> indication it has failed (either at translation or execution).

Surely defining a term pertaining to C compliance shouldn't
depend on requirements outside the C Standard such as POSIX.
Or do you mean something more like "portably POSIX compliant"?

> Preferably that 'result within standard' should also be within the
> spec for the program, and that in turn consistent with the needs of
> the user(s), but those are out of scope for the language. 

I would expect that whether a program is 'clc-compliant' (or
whatever other similar term is used) would depend only on
whether its behavior can be predicted reliably using the
Standard, not on anything having to do with the program's
specification (if it even has one at all).  Trying to
define the criteria that decide whether a program meets
a specification sounds even harder than trying to define
some sort of "portably correct program" criteria.


>> > More substantively: modulo bugs a conforming implementation should
>> > accept *and correctly execute* a clc-compliant program *unless it's
>> > too big* -- and then as Quality of Implementation it should give an
>> > appropriate diagnostic, although the standard doesn't require it.
>> 
>> This statement is circular:  a clc-compliant program is one that
>> portably works correctly, and conforming implementations must
>> correctly execute a clc-compliant program.  Obviously this must
>> be true, otherwise the program in question is not 'clc-compliant',
>> by definition.
>> 
> It's not circular, it's just vague; if I reasonably expect it to work,
> implementations should make it work unless they can't.

The statement quoted was the only one in the responded-to posting that
was anything like a definition of 'clc-compliant'.  That makes it
circular.  (The "unless too big" part is fuzzy, but that's neither
here nor there.)  You did give the start of a definition in the
followup, but of course that doesn't affect statements made about the
previous posting.


>> > On the other side, it must diagnose any program with a syntax error or
>> > constraint violation, but it is permitted to try to 'fix' such program
>> > into a valid and if lucky desired one.
>> 
>> Which is exactly the case under the existing Standard (absent
>> a #error directive).
>> 
>> > And it can have extensions that
>> > users intend and want, but mandate diagnosis in conforming mode. 
>> 
>> This statement appears to be discussing changing the definition
>> of the term "conforming implementation" in the Standard.  If so
>> then it is circularly self-contradictory -- it mandates diagnosis
>> for conditions that, by definition, the Standard does not
>> require diagnosing.
>> 
> Other way; if a program uses an extension that violates standard
> syntax or constraints -- as practically all do, and that's a working
> definition of 'extension' as opposed to 'implementation choice' --
> then a conforming implementation must (required by standard) diagnose,
> but may (by standard) then do anything, and should (IMO) accept using
> its definition of the extension.

There are two sorts of things that might be termed extensions:  those
that are syntax errors or constraint violations, and those that are
not SE/CV.  For SE/CV, the Standard already provides the behavior you
want -- must issue a diagnostic, then the compiler can do anything it
wants (not counting #error).  For extensions outside the range of
SE/CV, not diagnostic is required.  Do you mean to require compilers
(or runtimes) to diagnose all instances of undefined behavior?  Because
if a program doesn't have SE/CV, the only choices left are defined
(including unspecified and implementation-defined) and undefined
behavior.  For that matter, do you mean to require compliers/runtimes
to diagnose relying on unspecifed behavior or implementation-defined
behavior?

I simply don't understand which behaviors you mean to require
getting a diagnostic beyond SE/CV, which already require getting
a diagnostic.

> Formally this is the same as the prior point -- after diagnosis the
> compiler tries to DWIM. But for an extension it can have very high
> confidence about WIM, not just a guess.

I don't see how this is any different from how things are now.
SE/CV -- diagnostic required, can do anything.  Unspecified
behavior -- can do any of the different possibilities allowed.
Implementation-defined behavior -- must do what the implementation
says it will do.  Undefined behavior -- can do anything.  Which
ones of { unspecified behavior, implementation-defined behavior,
undefined behavior } do you mean to require diagnostics?


>> > And it *may* diagnose other errors, but in general there are many
>> > errors that are not practical to detect and thus cannot be rejected.
>> >
>> > IOW I agree with 'accept' mostly but 'reject' mostly not
>> 
>> I don't disagree with what I read as the spirit of the quoted
>> comments.  However, if there is some sort of objection to how these
>> terms are defined (and therefore what constitutes a "conforming
>> implementation"), I think the objectors should try writing a
>> complete replacement for section 4, "Conformance" (it's only eight
>> paragraphs).  If criticism is going to be offered, don't do it from
>> the sidelines, get out there on the playing field.  Don't want to
>> get out on the playing field?  Then be prepared for someone to
>> say "put up or shut up".
>
> I certainly don't have a better solution. I haven't seen a language
> conformance spec that could be accurately enforced except Ada, 
> and that only because for a while it had the US Defense Department
> spending loads of money on it, and it was done from scratch, and even
> so AIUI there were still serious disagreements on some (small) points.
> And it took quite a few years before people could use it. (And
> relatively few did or do, although I don't believe that's caused by
> the conformance spec, and personally I even like the language.)
>
> But to define what I consider 'decent' or 'satisfactory', and can
> reasonably argue others should also, I think my method works.

I'm sympathetic to where I think you're trying to go with
this.  However, I think actually doing it is much harder
than you think, because (a) actually defining the criteria
for a "good program" (or whatever we might call it) is
very difficult, and (b) even not counting the writing part,
getting people to agree on what the criteria should be
is also difficult, perhaps even moreso.  If someone wants
to lead the charge, I'm happy to applaud and cheer them
on;  at the same time I think it's unrealistic to expect
the chances of success to be even as high as 50%.  So...
is it into the valley of death for the Light Brigade?

On Sat, 03 Jul 2010 07:58:01 -0700, Tim Rentsch
<txr@alumni.caltech.edu> wrote:

> David Thompson <dave.thompson2@verizon.net> writes:
> 
> > On Thu, 17 Jun 2010 12:31:40 -0700, Tim Rentsch
> > <txr@alumni.caltech.edu> wrote:

> It still sounds like you're just saying that the terms the
> Standard uses don't meet your needs.  I get that they don't
> meet your needs, but that doesn't make them useless.
> 
If there is a good use for the universe set, I'd like to know it.

> >> > We've had several tries seeking a term
> >> > for the (useful!) category of programs that portably work correctly,
> >> > and the least bad IMO was 'clc-compliant'.
> >> 
> >> The term 'clc-compliant' seems reasonable, or at least plausible,
> >> but as a definition this statement falls short.  Unless there
> >> is some sort of definition of what it means to "work correctly",
> >> it says nothing.
> >> 
> > That is the hard part. My rough version is that a program works
> > correctly on some implementation if (each run of) it either produces
> > results consistent with (within the range specified by) a reasonable
> > understanding (mediated by discussion here if necessary) of the
> > standard
> 
> So...  you want a term for a program that portably works
> correctly, but you only require the program to run correctly
> on one implementation?  Where's the "portable" part?
> 
Sorry, I quantified sloppily, I meant 'with respect to some=any'.
For each implementation X, my program run on X should produce results
consistent with my understanding of the standard, or none -- but not
necessarily the same as on Y!=X. In my OpenSSL example, it produces
different results on different implementations so it's not s.c., but
if on any given implementation X it produces either the results I
expect (for X) or indicates error, I call that correct.

> > (C plus others applicable like POSIX), or gives a clear
> > indication it has failed (either at translation or execution).
> 
> Surely defining a term pertaining to C compliance shouldn't
> depend on requirements outside the C Standard such as POSIX.
> Or do you mean something more like "portably POSIX compliant"?
> 
If I intended a particular program to be POSIX, then yes. That was not
the best example, since POSIX already has its own conformance rules.
If I intended a program to be C + IEEEFP (or now C99 with the *option*
for 10559) I would say that. If I intended it to be C + 256M usable
memory I would say that. These and more are all useful-IMO categories
of programs that correspond to useful-IMO ranges of platforms. But (I
claim) I can use the same decision process for all. I need to say
which standards apply to each actual program, yes.

> > Preferably that 'result within standard' should also be within the
> > spec for the program, and that in turn consistent with the needs of
> > the user(s), but those are out of scope for the language. 
> 
> I would expect that whether a program is 'clc-compliant' (or
> whatever other similar term is used) would depend only on
> whether its behavior can be predicted reliably using the
> Standard, not on anything having to do with the program's
> specification (if it even has one at all).  Trying to
> define the criteria that decide whether a program meets
> a specification sounds even harder than trying to define
> some sort of "portably correct program" criteria.
> 
That's why I said preferably and out-of-scope. But it is my *reason*
for this: my goal is programs that do some desired thing, on many
platforms. I'm responsible for writing code that expresses that
desire; if my code is 'x-compliant' I claim each implementation is
responsible for carrying it out as written or indicating failure. 

> >> > And it can have extensions that
> >> > users intend and want, but mandate diagnosis in conforming mode. 
> >> 
> >> This statement appears to be discussing changing the definition
> >> of the term "conforming implementation" in the Standard.  If so
> >> then it is circularly self-contradictory -- it mandates diagnosis
> >> for conditions that, by definition, the Standard does not
> >> require diagnosing.
> >> 
> > Other way; if a program uses an extension that violates standard
> > syntax or constraints -- as practically all do, and that's a working
> > definition of 'extension' as opposed to 'implementation choice' --
> > then a conforming implementation must (required by standard) diagnose,
> > but may (by standard) then do anything, and should (IMO) accept using
> > its definition of the extension.
> 
> There are two sorts of things that might be termed extensions:  those
> that are syntax errors or constraint violations, and those that are
> not SE/CV.  For SE/CV, the Standard already provides the behavior you
> want -- must issue a diagnostic, then the compiler can do anything it
> wants (not counting #error).  For extensions outside the range of

I thought I said that. Maybe more than once.

> SE/CV, not diagnostic is required.  Do you mean to require compilers
> (or runtimes) to diagnose all instances of undefined behavior?  Because
> if a program doesn't have SE/CV, the only choices left are defined
> (including unspecified and implementation-defined) and undefined
> behavior.  For that matter, do you mean to require compliers/runtimes
> to diagnose relying on unspecifed behavior or implementation-defined
> behavior?
> 
No no no, I didn't say or mean that. I said that if the Standard
allows a range of possibilities as unspec or impl-def, for a given
construct in my program, the implementation must do something in that
range or indicate error. The Standard says (and you reiterate) the
first part; what I'm arguably adding is that the loose wording in 1p2
shouldn't be a loophole: the implementation must indicate, either at
translation or runtime, if it can't correctly execute my 'x-compliant'
program. I would like that indication to be specific and helpful, but
at a minimum it must NOT mimic the normal output of my program while
actually being silently wrong -- which UB can do.

> > I certainly don't have a better solution. I haven't seen a language
> > conformance spec that could be accurately enforced except <snip>
> > But to define what I consider 'decent' or 'satisfactory', and can
> > reasonably argue others should also, I think my method works.
> 
> I'm sympathetic to where I think you're trying to go with
> this.  However, I think actually doing it is much harder
> than you think, because (a) actually defining the criteria
> for a "good program" (or whatever we might call it) is
> very difficult, and (b) even not counting the writing part,
> getting people to agree on what the criteria should be
> is also difficult, perhaps even moreso.  If someone wants
> to lead the charge, I'm happy to applaud and cheer them
> on;  at the same time I think it's unrealistic to expect
> the chances of success to be even as high as 50%.  So...
> is it into the valley of death for the Light Brigade?

I agree it is hard. The aside in my first post was because the
Standard didn't accomplish it -- neither 'conforming' nor 's-c'
accurately identifies 'usefully portable' programs. I don't consider
that a serious problem, since we can (and I did) use other criteria.
To keep my aside short and get to the actual points, I dismissed it
more harshly than needed, and for that I'm sorry.

Perhaps an (always-suspect) analogy: to me it's like saying pilots on
airline X aren't good at handling baggage. It might be nice in some
cases if they were, but it's okay if they aren't because we can get
other people to handle baggage as long as the pilots fly the planes
safely to the right places. The Standard should -- and AFAICT except a
very few murky corners does -- define what I reasonably can expect the
execution of a given C program to do, and what I can't expect.
That's necessary and sufficient.

David Thompson <dave.thompson2@verizon.net> writes:

> On Sat, 03 Jul 2010 07:58:01 -0700, Tim Rentsch
> <txr@alumni.caltech.edu> wrote:
>
>> David Thompson <dave.thompson2@verizon.net> writes:
>> 
>> > On Thu, 17 Jun 2010 12:31:40 -0700, Tim Rentsch
>> > <txr@alumni.caltech.edu> wrote:
>[snip]
>> >> > We've had several tries seeking a term
>> >> > for the (useful!) category of programs that portably work correctly,
>> >> > and the least bad IMO was 'clc-compliant'.
>> >> 
>> >> The term 'clc-compliant' seems reasonable, or at least plausible,
>> >> but as a definition this statement falls short.  Unless there
>> >> is some sort of definition of what it means to "work correctly",
>> >> it says nothing.
>> >> 
>> > That is the hard part. My rough version is that a program works
>> > correctly on some implementation if (each run of) it either produces
>> > results consistent with (within the range specified by) a reasonable
>> > understanding (mediated by discussion here if necessary) of the
>> > standard
>> 
>> So...  you want a term for a program that portably works
>> correctly, but you only require the program to run correctly
>> on one implementation?  Where's the "portable" part?
>> 
> Sorry, I quantified sloppily, I meant 'with respect to some=any'.
> For each implementation X, my program run on X should produce results
> consistent with my understanding of the standard, or none -- but not
> necessarily the same as on Y!=X. In my OpenSSL example, it produces
> different results on different implementations so it's not s.c., but
> if on any given implementation X it produces either the results I
> expect (for X) or indicates error, I call that correct.

This sounds like a tautology.  Don't all programs produce results for
each implementation that are (in the context of the implementation in
question) consistent with the Standard, if that implementation is
conforming?  Or do you mean to change what it means to be consistent
with the Standard, or what it means for an implementation to be
conforming, or both?


> [snip] my goal is programs that do some desired thing, on many
> platforms. I'm responsible for writing code that expresses that
> desire; if my code is 'x-compliant' I claim each implementation is
> responsible for carrying it out as written or indicating failure.

Don't conforming implementations already do that (assuming we're
talking just about compliance with ISO C)?  If not then that sounds
like you think the Standard's notion of conformance should be
changed -- right?  If that's right then changed how?


>[snip]
>
>> SE/CV, not diagnostic is required.  Do you mean to require compilers
>> (or runtimes) to diagnose all instances of undefined behavior?  Because
>> if a program doesn't have SE/CV, the only choices left are defined
>> (including unspecified and implementation-defined) and undefined
>> behavior.  For that matter, do you mean to require compliers/runtimes
>> to diagnose relying on unspecifed behavior or implementation-defined
>> behavior?
>> 
> No no no, I didn't say or mean that. I said that if the Standard
> allows a range of possibilities as unspec or impl-def, for a given
> construct in my program, the implementation must do something in that
> range or indicate error. The Standard says (and you reiterate) the
> first part; what I'm arguably adding is that the loose wording in 1p2
> shouldn't be a loophole:

I don't know what you're getting at with this statement.
Can you be more specific?

> the implementation must indicate, either at
> translation or runtime, if it can't correctly execute my 'x-compliant'
> program. I would like that indication to be specific and helpful, but
> at a minimum it must NOT mimic the normal output of my program while
> actually being silently wrong -- which UB can do.

I'm not sure what you're saying here.  Do you mean a 'clc-compliant'
program can't have undefined behavior on any implementation?  Or
if it does then the UB must be diagnosed (on those implemenations
where the UB occurs)?  Or something else?