Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: do { quit; } else { }
Date: Fri, 11 Apr 2025 17:56:30 +0100
Organization: A noiseless patient Spider
Lines: 85
Message-ID: <vtbhjv$24api$1@dont-email.me>
References: <vspbjh$8dvd$1@dont-email.me> <8634enhcui.fsf@linuxsc.com>
 <vsph6b$ce6m$5@dont-email.me> <86ldsdfocs.fsf@linuxsc.com>
 <20250406161323.00005809@yahoo.com> <86ecy5fjin.fsf@linuxsc.com>
 <20250406190321.000001dc@yahoo.com> <86plhodtsw.fsf@linuxsc.com>
 <20250407210248.00006457@yahoo.com> <vt15lq$bjs0$3@dont-email.me>
 <vt2lp6$1qtjd$1@dont-email.me> <vt31m5$2513i$1@dont-email.me>
 <vt3d4g$2djqe$1@dont-email.me> <vt3iqh$2ka99$1@dont-email.me>
 <vt5fed$ccri$1@dont-email.me> <vt5js2$g1t7$1@dont-email.me>
 <20250409142303.00004645@yahoo.com> <87ikndqabc.fsf@nosuchdomain.example.com>
 <20250410115501.000037a5@yahoo.com> <vt8ei8$2vn84$1@dont-email.me>
 <20250410080629.532@kylheku.com> <vt94q5$3jjod$1@dont-email.me>
 <vt9628$3hhr8$3@dont-email.me> <vtammh$174ev$1@dont-email.me>
 <vtavn9$1dp7m$3@dont-email.me> <vtb8nv$1plb2$2@dont-email.me>
 <vtba81$1qfbm$1@dont-email.me> <vtbc6o$1te2o$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 11 Apr 2025 18:56:32 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="dd2082d654358406b52b51744c06eb0c";
	logging-data="2239282"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/cMu1CuZRxOx9WyuPWMOSp"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:U5yp296Pc6kx48U7w1atV+vhbqo=
Content-Language: en-GB
In-Reply-To: <vtbc6o$1te2o$1@dont-email.me>
Bytes: 5023

On 11/04/2025 16:24, David Brown wrote:
> On 11/04/2025 16:50, bart wrote:

>>> declaration-specifiers:
>>>      storage-class-specifier declaration-specifiers opt
>>>      type-specifier declaration-specifiers opt
>>>      type-qualifier declaration-specifiers opt
>>>      function-specifier declaration-specifiers opt
>>>      alignment-specifier declaration-specifiers opt
>>
>> That always reads to me like 'lots of twisty windy passages, all alike'.
> 
> Try reading it without your usual anti-C prejudice.  Perhaps read the 
> whole section of the standard.
> 
>>
>>> If the order were to be strictly specified, there would need to be a 
>>> half-dozen more named and defined specifier lists in the syntax.
>>
>> This is the similar feature for my syntax, a bit of BNF:
>>
>>    typedef = [scopeattr] 'type' name = typespec
>>
>> It does a bit more than C's 'typedef' in that such names can be 
>> exported, to render them visible to modules that import this one.
>>
> 
> The C syntax for declarations here is for /all/ declarations in C.  It's 
> not just for typedefs in a simple little toy language. 

That's not right. You pasted part of 6.7p1. The full syntax for 
declarations comprises all of 6.7.p1, plus 6.7.1p1, 6.7.2p1, 6.7.2p2 
(constraints to do with the ordering of long, int etc), 6.7.2.1, 
6.7.2.2, 6.7.3, 6.7.6, 6.7.7, and 6.7.8.


(And yes, if you
> are going to make absurd claims about your language in comparison to C, 
> you can expect to hear that it is a toy in comparison C.)

Really? Please show /any/ declaration in C that I can't write in mine, 
but in a saner and less convoluted manner. Please define /any/ data 
structure that I can't express.

I could spend all day showing absurdity after absurdity in C. And you're 
saying /my/ language is a toy?!

My language /has/ a module scheme. All that palaver about type 
compatability just doesn't arise, because of careful language design.

My language /has/ the ability to import and export types, structs, 
enums, macros; anything that can be named.

My language /has/ named and default arguments. It /has/ reference 
parameters. It /has/ multiple function returns.

My language /has/ embedded text and binary files (and in a far simpler 
manner than proposed for C23).

Lots more, and it does it with a sane syntax

Still think it's a toy?

(Silly question, of source you will say Yes.)

>> That it makes it easier to parse?
>>
> 
> Who cares?  That's irrelevant to the language design, except for toys 
> where the only user is the person who writes the tools.

Humans have to parse it too. C must be the only non-esoteric language 
where you need to use third-party tools (CDECL etc) to make sense of 
type-declarations. Either that or follow complex spirular algorithms to 
decade them.

A complete fail in my view.

Yes, your tools (thanks to 1000s of man-years of effort) are superior 
and more expansive that any of mine**, but your language is still a 
turd, sorry. All those tools can do is polish it.

(** in some ways, but not in the ways /I/ value.)