Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Tue, 17 Sep 2024 05:56:02 -0700
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <861q1ibfrx.fsf@linuxsc.com>
References: <vab101$3er$1@reader1.panix.com> <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> <20240909100944.715@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Tue, 17 Sep 2024 14:56:03 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5475264e673852879913d2eef8867355";
	logging-data="3696824"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+SPIoRLpLfYOW1SkdLbdcO+I9duwsVTI8="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:4YQMWQJoV/0HtFZLmoWK4lyFewM=
	sha1:BiV5MmcCKx34EcY77bECofHPBcQ=
Bytes: 4067

Kaz Kylheku <643-408-1753@kylheku.com> writes:

> 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.

This critique is off base.  The C standard is a reference, not a
tutorial.  If Kaz thinks the grammar given in the C standard is not
up to the task *for the document it is part of*, he should post a
proposed replacement.