Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Mon, 9 Sep 2024 17:29:56 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <20240909100944.715@kylheku.com>
References: <vab101$3er$1@reader1.panix.com> <87mskwy9t1.fsf@bsb.me.uk>
 <vanq4h$3iieb$1@dont-email.me> <875xrkxlgo.fsf@bsb.me.uk>
 <vapitn$3u1ub$1@dont-email.me> <87o75bwlp8.fsf@bsb.me.uk>
 <vaps06$3vg8l$1@dont-email.me> <871q27weeh.fsf@bsb.me.uk>
 <20240829083200.195@kylheku.com> <87v7zjuyd8.fsf@bsb.me.uk>
 <20240829084851.962@kylheku.com> <87mskvuxe9.fsf@bsb.me.uk>
 <vaq9tu$1te8$1@dont-email.me> <875xrivrg0.fsf@bsb.me.uk>
 <20240829191404.887@kylheku.com> <86cylqw2f8.fsf@linuxsc.com>
 <871q2568vl.fsf@nosuchdomain.example.com> <vavmbk$13k4n$1@dont-email.me>
 <87cylo494u.fsf@nosuchdomain.example.com> <vb09gd$16mr5$1@dont-email.me>
 <20240831195350.785@kylheku.com> <86mskrrvco.fsf@linuxsc.com>
 <vbj9qb$1qi2h$1@dont-email.me> <vbkbc1$1u33o$1@dont-email.me>
 <vbkcqi$1v2vr$1@dont-email.me>
Injection-Date: Mon, 09 Sep 2024 19:29:56 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="12fcfbc5d48fa36314df466b473f18b1";
	logging-data="2623042"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/4Hk7UFSYmgnXoY2PWrsnZDpvXKyWAjKY="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:fNUZXN9DXt9DrLHD73rmVa4mNrw=
Bytes: 4866

On 2024-09-08, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 08.09.2024 16:12, James Kuyper wrote:
>> On 9/8/24 00:39, Janis Papanagnou wrote:
>> ...
>>> That's why I immediately see the necessity that compiler creators need
>>> to know them in detail to _implement_ "C". And that's why I cannot see
>>> how the statement of the C-standard's "most important purpose" would
>> sound reasonable (to me). ...
>> 
>> I agree - the most important purpose is for implementors, not developers.
>> 
>>> ... I mean, what will a programmer get from the
>>> "C" standard that a well written text book doesn't provide?
>> 
>> What the C standard says is more precise and more complete than what
>> most textbooks say.
>
> Exactly. And this precision is what makes standard often difficult
> to read (for programming purposes for "ordinary" folks).

The C grammar is not presented in a nice way in ISO C.

It uses nonsensical categories. For instance a basic expression like A
is considered a unary-expression.  A newcomer looking at the
grammar for assignment will be wondering how on Earth the   A
in  A = B  is a unary expression, when it contains no unary operator.

The unary-expression is not given in the immediately preceding section,
and no section references are given; you have to go searching through
the document to find it.

I also suspect programmers not versed in parsing and grammars will not
intuit that assignment associates right to left. Someone who remembers
their compiler course from university will know that the right hand side
"unary-expression assignment-operator assignment-expression"
has the assignment-expression on the right, and is therefore
identified as right-recursive, and that leads to right association. 

I strongly suspect that the vast majority of the C coders on the planet
(as well as users of other languages that have operator grammars) refer
to operator precedence tables that fit on one page, rather than flipping
around in a telescopic grammar that goes on for pages.

The standard for a language which has operators with precedence
should give a precedence table. The grammar for assignment should
be given as <expr> = <expr>, where you refer to the table if you
want to know how a = b = c or a + b = c are parsed. That would be the
most understandable presentation, or at least the most widely used one
which programmer are used to from books and tutorials.

Books and tutorials about C could just carefully copy and paste the
table from the standard, and be confident that they have the correct
info which matches how the language is defined.

Lastly, the grammar presentation in ISO C is not actually agnostic of
parsing technology. It users left recursion which isn't LL(1) and
therefore presents a challenge to someone writing a recursive-descent
parser, who must factor the grammar.

For a grammar specification to be directly usable to the widest scope of
implementation techniques---if that were a goal---it would have to
be left-factored, where necessary, to meet that goal.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca