A lurker's take on C.L.C pedantry

[Chris H]

No. Or, rather, I disagree. Since ANSI (as you know) has adopted ISO
C99 as its official C standard, referring to C89 simply as "ANSI C"
is, pedantically speaking, incorrect.


Section numbers are part of the standard documents, not part of the
language they describe. The ANSI C89 document and the ISO C90
document describe, as far as I know, exactly the same language.

With a different Rational

 

[Mark Wooding]

Incidentally, my "Yes, it does", quoted above, was originally followed
by text that explained *why* "it does".

Indeed. Sorry: I didn't mean to imply that /you/ weren't actually
providing valid arguments, rather than making unfounded assertions.

For the record, I think I agree that a more relaxed approach to
topicality in this group would be good.

It's just that the Python reference was too good to miss.

-- [mdw]

 

[James Dow Allen]

You write as though pedantry were a bad thing. This is a point of
view that I've always struggled to understand.

Merriam-Webster's Dictionary is widely cited by
Usanians. Since Mr. Heathfield seems to take "pedant"
as approbatory, perhaps this is another instance
of divergence between the dialects of Modern English.

* * * * * * * * * * * * * * * *
From Merriam Webster 10th Collegiate Dictionary;
Copied without permission:


pedant n, (1588) [MF, fr. It pedante]
1 obs : a male schoolteacher
2a : one who makes a show of knowledge
2b : one who is unimaginative or who unduly emphasizes
minutiae in the presentation or use of knowledge
2c : a formalist or precisionist in teaching

pedantic /pi-'dan-tik/ adj, adv: -ally, (ca. 1600)
1 : of, relating to, or being a pedant
2 : narrowly, stodgily, and often ostentatiously learned
3 : unimaginative, pedestrian

pedantry n, pl: -ries, (1612)
1 : pedantic presentation or application of knowledge
or learning
2 : an instance of pedantry


"Dogmatic" is another word sometimes used to describe a class
of postings:

dogma n, pl -s or -ata (1638)
[L dogmat-, dogma, fr. Gk dokein to seem]
1a : something held as an established opinion;
esp : a definite authoritative tenet
1b : a code of such tenets <pedagogical>
1c : a point of view or tenet put forth as authoritative
without adequate grounds
2 : a doctrine or body of doctrines concerning faith or
morals formally stated and authoritatively proclaimed
by a church

dogmatic also -al adj, adv -ally, n -alness (ca. 1681)
1 : characterized by or given to the use of dogmatism <a critic>
2 : of or relating to dogma (syn : see dictatorial)

* * * * * * * * * * * * * * * *

Let's work with two specific examples. I say: avoid initializers;
and avoid goto's. But I do use "unneccessary" initializers sometimes
(esp. in short functions), and there are several situations where
goto is the best option.

Recently, someone posted a program and asked for comment.
I'd pointed out earlier that initializion may be asking for
trouble, and was grateful to OP who demonstrated this so clearly:
his code initialized the same variable in *three* different places,
only one of which had any effect; I explained how this would
never have happened if OP had simply followed my dictum to
*avoid initializers*. Mr. Heathfield made no attempt to address
or acknowledge that the initializer led to trouble, instead
repeating dogmatically that initializers were not to be avoided.

On the other hand, Mr. Heathfield has written, on more than one
occasion, that there is *never* a good reason to use goto.
I myself use goto's less than some of the linux/gnu coders --
parse_param() in posix/wordexp.c has 39 goto's and five labels --
but I've presented examples of goto's which Mr. Heathfield
has never attempted to refute: he'll omit mention of goto's
for a few weeks, then pontificate again that there is *never*
a good reason to use goto.

Goto examples I've presented previously include the trivial:

for (numpile = 1; numpile <= plast; numpile++)
for (numrem = 1; numrem <= psize[plast]; numrem++)
if (WINNER)
goto move;
/* no winning move ... make a simple default move */
numpile = numrem = 1;
move:
printf("My move: %d piles and %d beans per pile.\n",
numpile, numrem);

and the more interesting goto discussed at
http://james.fabpedigree.com/gotoalt.htm
Only one programmer has ever taken the time to demonstrate
a goto-less version of the code at this webpage: his version
eliminates the goto and label by using three forever-loops,
and adding four if's, two else's, two breaks, four state-change
fragments, a duplicated initialization, and a return from
inner loop. Mr. Heathfield is welcome to submit his
own goto-free version.


Richard Heathfield: Pedantic or Dogmatic? You decide.

 

[Richard Bos]

NO IT DOES NOT

Yes. People could discuss SPECIFICALLY The Standard in comp..std.c but
it DID NOT and DOES NOT change comp.lang.c

Yes BUT it STILL DOES NOT CHANGE COMP.LANG.C

And it STILL DOES NOT CHANGE COMP.LANG.C and so on and so on.

And ANYTHING ELSE UNDER ITS ORIGINAL REMIT.

and the 10 of you can be happy there but DO NOT TELL ME WHAT I CAN AND
CAN NOT POST HERE WHEN YOU DISAGREE WITH WHAT IS THE CHARTER OF THIS
GROUP

You do realise what is commonly said about people who post in all caps,
don't you?

Richard

 

[Kenny McCormack]

You do realise what is commonly said about people who post in all caps,
don't you?

Around here, they mostly make inquiries into the state of your shift key.

(That is, they tend to treat it as a hardware problem)

 

[James Kuyper]

Merriam-Webster's Dictionary is widely cited by
Usanians. Since Mr. Heathfield seems to take "pedant"
as approbatory, perhaps this is another instance
of divergence between the dialects of Modern English.

I'm a US citizen, but I've learned, just like RH, to treat it as an
unintended compliment. This is not so much a matter of how the word is
defined by the dictionaries, as it is a matter of how the word is
actually used. It's not even a matter of the word having a different
meaning for some people; the people using it understand the word to mean
pretty much what the dictionaries say it means; but it has been my
experience that the people using it tend to misjudge the applicability
of that definition.

* * * * * * * * * * * * * * * *
From Merriam Webster 10th Collegiate Dictionary;
Copied without permission:


pedant n, (1588) [MF, fr. It pedante]
1 obs : a male schoolteacher
2a : one who makes a show of knowledge

There's nothing inherently wrong with showing that you have knowledge of
a subject; if someone asks for help with C in a public forum like this
one, and you provide that help, you've just shown that you know more
about C than the person you've helped. What makes a "show of knowledge"
a negative thing is if is done out of vanity (or if the knowledge does
not actually exist). The problem is, some people will call others
pedants because of a show of knowledge that had nothing to do with
vanity; this is their way of expressing their misjudgment that it was a
matter of vanity.

2b : one who is unimaginative or who unduly emphasizes
minutiae in the presentation or use of knowledge

Note the key work "unduly". That's inherently a matter of judgement.
There's nothing wrong with a due amount of "emphasis on minutiae in the
presentation or use of knowledge", it's only when the emphasis becomes
unduly great that the word "pedant" is justified. Some people label
others as pedants for showing no more than a due amount of emphasis on
those things; this is their way of expressing their misjudgment that the
emphasis was excessive.

2c : a formalist or precisionist in teaching

There's a place for formalism and precision in teaching; these are vices
only when done to excess. Some people label others as 'pedants' for
using no more formalism or precision than is entirely appropriate. This
is their way of expressing their misjudgment that it is excessive.

 

[Keith Thompson]

Keith Thompson said:


Not really. After all, it's the C language that was standardised by
ANSI. The fact that they've done it again since does not invalidate
the fact that they did it the first time. Even if only for
historical reasons, we need to bear in mind that, leading up to the
time it was standardised in 1989 (and certainly prior to ISO/IEC
9899), "ANSI C" *was* the term that everyone used, without fear of
contradiction, to describe ANSI C.

I think ANSI would disagree.

I understand your point, and disagree with it.

Really? Why?

Then why not call the ISO C90 document ANSI C89? After all, they are
both language definitions, and they both define exactly the same
language, and the ANSI C89 document is prior art.

Because it's not the same *document*.

 

[Keith Thompson]

Keith Thompson said:

Why? Look, I *remember* this. I started learning C in 1989 (which
was quite good timing actually, because I was spared K&R C), and
"ANSI C" was *the* phrase on everyone's lips. In 1990, when I first
started writing C for money, "ANSI C" was the term used in
documentation by Microsoft, by Borland, and in a number of
textbooks on the subject, including K&R. With respect, if ANSI
disagrees that people used the term "ANSI C" to describe C89,
they're wrong.

So your position is that:

-- The American National Standards Institute (ANSI) recognizes one and
only one version of the C language, the version described by the
ISO standard that was published in 1999 (presumably ANSI recognizes
the three TCs as well)

*and*

-- The unqualified phrase "ANSI C" properly refers only to the version
of the language described by the standard published by ANSI in
1989, which ANSI itself no longer recognizes.

Does that sum it up?

[...]

Agreed, because of the section numbers. But *you* say the two
documents describe the same language

Yes, two different documents describing the same language. Do you
disagree?

- the language that is fondly
(and, I would argue, correctly) described by a great many people as
"ANSI C".

I agree that the phrase "ANSI C" generally refers to the language, not
to the document. As I've said, I disagree that that usage is strictly
correct. The common and simple convention of referring to C89, C90,
or C99 (with or without "ANSI" or "ISO") suffices to avoid any
ambiguity.

 

[James Kuyper]

Keith Thompson said: ....

No, that is not my position. I have no opinion on what ANSI
recognises. I'm talking about the name used by a great many people
to describe C89 - in my opinion, correctly.


No, not exactly, but you're not far off. ANSI's opinion doesn't
strike me as being particularly relevant here.

ANSI's opinion isn't relevant to the accuracy of applying ANSI as an
adjective to a type of C? If you were only talking about common usage, I
might agree - but you're also explicitly claiming that this particular
common usage also happens to be correct usage, and I would expect ANSI's
opinions to be very relevant to the truth of that assertion.

 

[James Dow Allen]

James Dow Allen may have written the following, but I have my
doubts, since James normally strikes me as being an eminently clear
thinker who is slow to cast undeserved aspersions on people:

I'm afraid it really was me (although if you follow Barbour's
interesting views on time the 'me' today is not the the same as
'me' yesterday). I'm afraid I've been in a bad mood lately, for
reasons wholly unrelated to programming or Usenet. Sorry for
misdirecting abuse. It was particularly inappropriate since
Richard Heathfield is an important member of this n.g and a
programmer whose opinions are always worthy of attention.

Perhaps you could provide a message ID, so that I can comment with
reference to the original discussion.

Firstly, I would just like to point out that it's rarely a
good idea to use goto (in fact, I've never come across a good
reason to use it in "real" code).

I *did* misquote you (sorry, again). In this (and some other
messages) you imply that *you've* never seen an appropriate goto,
*not* that they don't exist. This confuses some of us, since
there seem to be plenty of examples where 'goto' *is* the least
of evils. I take it as a challenge: "Here's a specific piece
of code ... will you agree, Richard, that *this* goto is best
way to code?"

Again, a requirements spec would be a good move if you want people
to take this seriously.

The trivial fragment seems clear enough, even in isolation.
I don't think my website is that hard to navigate, but if
you have time to take up the challenge, e-mail me (gmail
name is jamesdowallen) and I'll send you criteria and specific
links.

James Dow Allen

 

[James Dow Allen]

James Dow Allen may have written the following, but I have my
doubts, since James normally strikes me as being an eminently clear
thinker who is slow to cast undeserved aspersions on people:

I'm afraid it really was me (although if you follow Barbour's
interesting views on time the 'me' today is not the the same as
'me' yesterday). Imay have been in a bad mood lately, for
reasons wholly unrelated to programming or Usenet. Sorry for
misdirecting abuse. It was particularly inappropriate since
Richard Heathfield is an important member of this n.g and a
programmer whose opinions are always worthy of attention.

Perhaps you could provide a message ID, so that I can comment with
reference to the original discussion.

Firstly, I would just like to point out that it's rarely a
good idea to use goto (in fact, I've never come across a good
reason to use it in "real" code).

I *did* misquote you (sorry, again). In this (and some other
messages) you imply that *you've* never seen an appropriate goto,
*not* that they don't exist. This confuses some of us, since
there seem to be plenty of examples where 'goto' *is* the least
of evils. I take it as a challenge: "Here's a specific piece
of code ... will you agree, Richard, that *this* goto is best
way to code?"

Again, a requirements spec would be a good move if you want people
to take this seriously.

The trivial fragment seems clear enough, even in isolation.
I don't think my website is that hard to navigate, but if/when
you find that you *do* have time to take up the challenge, e-mail
me (gmail name is jamesdowallen) and I'll send you criteria and
specific links.

James Dow Allen

 

[:)]

I'm afraid it really was me (although if you follow Barbour's
interesting views on time the 'me' today is not the the same as
'me' yesterday). I'm afraid I've been in a bad mood lately, for
reasons wholly unrelated to programming or Usenet. Sorry for
misdirecting abuse. It was particularly inappropriate since
Richard Heathfield is an important member of this n.g and a
programmer whose opinions are always worthy of attention.

Hello,

I have not been in NGs for long, and I am by no means an expert to
comment, but I would like to say that Mr Richard Heathfield is a
respected member, at least that is my opinion.

 

[:)]

So a name not seen before, the title "Mr". This redefines blatant sock
puppetry.

Peace.

 

[CBFalconer]

Richard wrote:



Peace.

FYI Richard the nameless is a well known c.l.c troll. Best plonked.

 

[Gene]

On the topic of who is knowledgeable and who isn't, there was nice a
thread here in late February, subject line: ``interesting math
problem''.

The only one who solved the problem, giving a correct algorithm in
the form of working C code (ISO standard and all) was me.

I missed that message.  I saw your Lisp solution, bit not a C one.
Can you post a link, please?  (I can't find it but Google groups is
unreliable or I may just be missing the obvious.)

It was shocking. Nobody else in this group actually knew how to
solve a moderately complex, self-contained programming problem that
can be coded in a few dozen lines of strictly conforming ISO
C---i.e. nothing approaching the complexity of some real-world
software engineering problem.

Woah there!  How can you conclude that no one knew how to solve it?
The reason I did not post a solution is that it seemed to be one of
those problems that is better solved in a high-level language.  I saw
no reason to post another non-C solution and I don't much care for C
programs that are "translated down" for HLL solutions (though
sometimes that is the best we can do).

'Gene' has posted a C solution that emulates these high-level
structures in C.  It has the expression backwards so it does not find
solutions to the problem as posted, but that is trivial to change.  I
don't want to detract from that fine solution, but it not "natural" C.

Your fighting talk and my nagging feeling that there might be a simple
solution in C lead me the code posted below.  I doubt is anything like
the best way to do this in C and, being un-commented, it is rather
cryptic but I am happy with it.  It counts the possible trees using
mixed-base counter.  These are mapped into tree shapes that can
evaluated (or printed) using a set of assignments for the values and
the operators.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdbool.h>
#include <math.h>
#include <float.h>

typedef struct tree {
     struct tree *arg[2];

} tree;

bool next_tree(int n, int *sum)
{
     int p = 1;
     while (p < n && sum[p] == n - p) p++;
     if (p == n)
          return false;
     int d = sum[p] + 1;
     while (p) sum[p--] = d;
     return true;

}

tree *tree_make(int nops, int *counter, tree *nodes)
{
     tree *stack[nops + 1], **sp = stack, *next_node = nodes;
     *sp++ = 0;
     for (int i = nops; i > 0; i--) {
          *sp++ = 0;
          int shift = counter[i-1] - counter;
          while (shift--) {
               tree *n = next_node++;
               sp -= 2;
               n->arg[0] = sp[0];
               n->arg[1] = sp[1];
               *sp++ = n;
          }
     }
     return stack[0];

}

double tree_eval_aux(tree *e, double **args, char **ops)
{
     if (e) {
          double a = tree_eval_aux(e->arg[0], args, ops);
          char op = *(*ops)++;
          double b = tree_eval_aux(e->arg[1], args, ops);
          switch (op) {
          case '+': return a + b;
          case '-': return a - b;
          case '*': return a * b;
          case '/': return a / b;
          }
          return NAN;
     }
     else return *(*args)++;

}

void tree_print_aux(tree *e, double **args, char **ops)
{
     if (e) {
          putchar('(');
          tree_print_aux(e->arg[0], args, ops);
          putchar(*(*ops)++);
          tree_print_aux(e->arg[1], args, ops);
          putchar(')');
     }
     else printf("%g", *(*args)++);

}

void tree_print(int nops, int *counter, double *args, char *ops)
{
     tree nodes[nops];
     tree_print_aux(tree_make(nops, counter, nodes), &args, &ops);

}

double tree_eval(int nops, int *counter, double *args, char *ops)
{
     tree nodes[nops];
     return tree_eval_aux(tree_make(nops, counter, nodes), &args, &ops);

}

double find_max_tree(int nops, double *args, char *ops, int *best)
{
     int tree_number[nops + 1];
     memset(tree_number, 0, sizeof tree_number);
     tree_number[0] = nops;
     double max = -DBL_MAX;
     do   {
          double r = tree_eval(nops, tree_number, args, ops);
          if (isfinite(r) && r > max) {
               max = r;
               memcpy(best, tree_number, sizeof tree_number);
          }
     } while (next_tree(nops, tree_number));
     return max;

}

int main(void)
{
     double values[] = {2, 2, 3, 3, 4, 4, 5, 5};
     char operators[] = "/-/-/-/";
     int n = strlen(operators);
     int best[n + 1];
     double max_value = find_max_tree(n, values, operators, best);
     tree_print(n, best, values, operators);
     printf(" = %g\n", max_value);
     return 0;

}

Thanks Ben. The error was swapping the args in these two lines (which
are correct below):

sprintf(i->cont->pstr, "(%s%c%s)", i->encl->pstr, expr[i->op], i-

pstr);

i->cont->pval = eval(i->encl->pval, i->op, i->pval);

(original post here: http://groups.google.com/group/comp.lang.c/msg/9e3b2679e800b7ee)

I realized it after I posted, but assumed no one cared because the
thread ended.

If you keep transforming my solution by algebra, implementing the call
stack explicitly, you eventually get to your solution above. Not
surprising, but still cool.

The notion of "natural C," seems a bit nebulous, though. Since the
closures are downward, you're really only emulating a language with
nested procedure. The idiom of passing down a pointer to a record on
the
call stack to get the same effect is pretty common. Is this "natural
Ada?"

with Ada.Text_IO;

-- Enumerate all ways to parenthesize a certain expression.
procedure Enumerate_Parens is

procedure Parenthesize(Expr : in String;
Continue : access procedure
(Expr : in String)) is

Op : Positive := Expr'First + 1;

procedure Parenthesize_Rhs(Lhs : in String) is

procedure Apply_Op(Rhs : in String) is
begin
Continue("(" & Lhs & Expr(Op) & Rhs & ")");
end Apply_Op;

begin
Parenthesize(Expr(Op + 1 .. Expr'Last), Apply_Op'Access);
end Parenthesize_Rhs;

begin
if Expr'Length = 1 then
Continue(Expr);
else
while Op < Expr'Last loop
Parenthesize(Expr(Expr'First .. Op - 1),
Parenthesize_Rhs'Access);
Op := Op + 2;
end loop;
end if;
end Parenthesize;

begin
Parenthesize("2/2-3/3-4/4-5/5", Ada.Text_IO.Put_Line'Access);
end;

Sorry for the OT language...

Gene

 

[Ben Bacarisse]

Thanks Ben. The error was swapping the args in these two lines (which
are correct below):

sprintf(i->cont->pstr, "(%s%c%s)", i->encl->pstr, expr[i->op], i-

pstr);

i->cont->pval = eval(i->encl->pval, i->op, i->pval);

(original post here: http://groups.google.com/group/comp.lang.c/msg/9e3b2679e800b7ee)

I realized it after I posted, but assumed no one cared because the
thread ended.

If you keep transforming my solution by algebra, implementing the call
stack explicitly, you eventually get to your solution above. Not
surprising, but still cool.

Interesting, I did not spot that.

The notion of "natural C," seems a bit nebulous,

Oh, entirely. I'm sure it varies from person to person and probably
from day to day!. A key quantity (in my mind) is the degree to which
the programmer is effectively translating down from a higher-level
language. Even this is too nebulous to be very useful.

though. Since the closures are downward, you're really only
emulating a language with nested procedure. The idiom of passing
down a pointer to a record on the call stack to get the same effect
is pretty common.

I confess I did not spot that fact that your closures were all
"downward". My excuse is that, when the problem first came up, I
wanted to avoid studying other people's solutions because I found it
interesting and wanted to think about it myself. Later, I failed to
correct that omission.

Is this "natural Ada?"

<snip Ada>
Not really an Ada person, but it looks entirely reasonable.