Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Wed, 6 Nov 2024 14:40:52 +0000
Organization: A noiseless patient Spider
Lines: 142
Message-ID: <vgfv5l$25hs6$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <vg0t3j$2ruor$1@dont-email.me>
 <78eabb4054783e30968ae5ffafd6b4ff2e5a5f17@i2pn2.org>
 <vg2g37$37mh3$1@dont-email.me> <6724CFD2.4030607@grunge.pl>
 <vg2llt$38ons$1@dont-email.me>
 <2491a699388b5891a49ef960e1ad8bb689fdc2ed@i2pn2.org>
 <b681ee05856e165c26a5c29bf42a8d9d53843d6d@i2pn2.org>
 <vg2ttn$3a4lk$1@dont-email.me> <vg33gs$3b8n5$1@dont-email.me>
 <vg358c$3bk7t$1@dont-email.me> <vg37nr$3bo0c$1@dont-email.me>
 <vg3b98$3cc8q$1@dont-email.me> <vg5351$3pada$1@dont-email.me>
 <vg62vg$3uv02$1@dont-email.me> <vg8a84$euka$1@dont-email.me>
 <vg8koq$gpsg$1@dont-email.me> <vgat50$112jp$1@dont-email.me>
 <vgb8if$13ioj$1@dont-email.me> <vgbhkt$155v2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 06 Nov 2024 15:40:54 +0100 (CET)
Injection-Info: dont-email.me; posting-host="425dce3b00381c91a014107c93c4293b";
	logging-data="2279302"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX197958uo+RfZmzvX9ouiy0j"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:gehPB8nvQ8tupF+ADS9uvEh4kR8=
In-Reply-To: <vgbhkt$155v2$1@dont-email.me>
Content-Language: en-GB
Bytes: 7416

On 04/11/2024 22:25, David Brown wrote:
> On 04/11/2024 20:50, Bart wrote:
>> On 04/11/2024 16:35, David Brown wrote:
>>> On 03/11/2024 21:00, Bart wrote:
>>
> 
>> Here is a summary of C vs my language.
>>
> 
> <snip the irrelevant stuff>
> 
>>
>>> I am very keen on keeping the concepts distinct in cases where it 
>>> matters.
>>
>> I know, you like to mix things up. I like clear lines:
>>
>>    func F:int ...              Always returns a value
>>    proc P  ...                 Never returns a value
>>
>>
> 
> Oh, you /know/ that, do you?  And how do you "know" that?  Is that 
> because you still think I am personally responsible for the C language, 
> and that I think C is the be-all and end-all of perfect languages?

> I agree that it can make sense to divide different types of "function". 
> I disagree that whether or not a value is returned has any significant 
> relevance.  I see no difference, other than minor syntactic issues, 
> between "int foo(...)" and "void foo(int * result, ...)".

I don't use functional concepts; my functions may or may not be pure.

But the difference between value-returning and non-value returning 
functions to me is significant:

                   Func  Proc
return x;         Y     N
return;           N     Y
hit final }       N     Y
Pure              ?     Unlikely
Side-effects      ?     Likely
Call within expr  Y     N
Call standalone   ?     Y

Having a clear distinction helps me focus more precisely on how a 
routine has to work.

In C, the syntax is dreadful: not only can you barely distinguish a 
function from a procedure (even without attributes, user types and 
macros add in), but you can hardly tell them apart from variable 
declarations.

In fact, function declarations can even be declared in the middle of a 
set of variable declarations.

You can learn a lot about the underlying structure of of a language by 
implementing it. So when I generate IL from C for example, I found the 
need to have separate instructions to call functions and procedures, and 
separate return instructions too.

> If you have a function (or construct) that returns a correct value for 
> inputs 1, 2 and 3, and you never pass it the value 4 (or anything else), 
> then there is no undefined behaviour no matter what the code looks like 
> for values other than 1, 2 and 3.  If someone calls that function with 
> input 4, then /their/ code has the error - not the code that doesn't 
> handle an input 4.

No. The function they are calling is badly formed. There should never be 
any circumstance where a value-returning function terminates (hopefully 
by running into RET) without an explicit set return value.


> I agree that this a terrible idea.
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523>
> 
> But picking one terrible idea in C does not mean /everything/ in C is a 
> terrible idea!  /That/ is what you got wrong, as you do so often.

What the language does is generally fine. /How/ it does is generally 
terrible. (Type syntax; no 'fun' keyword; = vs ==; operator precedence; 
format codes; 'break' in switch; export by default; struct T vs typedef 
T; dangling 'else'; optional braces; ... there's reams of this stuff!)

So actually, I'm not wrong. There have been discussions about all of 
these and a lot more.

>> Can you tell me which other current languages, other than C++ and 
>> assembly, allow such nonsense?
> 
> Python.
> 
> Of course, it is equally meaningless in Python as it is in C.

Python at least can trap the errors. Once you fix the unlimited 
recursion, it will detect the wrong number of arguments. In C, before 
C23 anyway, any number and types of arguments is legal in that example.


> I defend it if that is appropriate.  Mostly, I /explain/ it to you.  It 
> is bizarre that people need to do that for someone who claims to have 
> written a C compiler, but there it is.

It is bizarre that the ins and outs of C, a supposedly simple language, 
are so hard to understand. Like the rules for how many {} you can leave 
out for a initialising a nested data structure. Or how many extra ones 
you can have; this is OK:

    int a = {0};

but not {{0}} (tcc accepts it though, so which set of rules is it using?).

Or whether it is a static followed by a non-static declaration that is 
OK, or whether it's the other way around.

> I'm glad you didn't - it would be a waste of effort.

I guessed that. You seemingly don't care that C is a messy language with 
many quirks; you just work around it by using a subset, with some help 
from your compiler in enforcing that subset.

So you're using a strict dialect. The trouble is that everyone else 
using C will either be using their own dialect incompatible with yours, 
or are stuck using the messy language and laid-back compilers operating 
in lax mode by default.

I'm interested in fixing things at source - within a language.

> You /do/ understand that I use top-quality tools with carefully chosen 
> warnings, set to throw fatal errors, precisely because I want a language 
> that has a lot more "lines" and restrictions that your little tools? 
> /Every/ C programmer uses a restricted subset of C - some more 
> restricted than others.  I choose to use a very strict subset of C for 
> my work, because it is the best language for the tasks I need to do.  (I 
> also use a very strict subset of C++ when it is a better choice.)

I'd guess only 1% of your work with C involves the actual language, and 
99% using additional tooling.

With me it's mostly about the language.