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: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Wed, 6 Nov 2024 16:47:50 +0100
Organization: A noiseless patient Spider
Lines: 260
Message-ID: <vgg337$26880$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>
 <vgfv5l$25hs6$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 16:47:52 +0100 (CET)
Injection-Info: dont-email.me; posting-host="8d7a8d5cafd9cd3ecfae6db42c4dba2a";
	logging-data="2302208"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19E7/kAHODDhwFEWJC2i9JE5WwAQeDs5Rw="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:nBYhlZnVT2GOA9Kr6zofnk6xDFA=
In-Reply-To: <vgfv5l$25hs6$1@dont-email.me>
Content-Language: en-GB
Bytes: 12148

On 06/11/2024 15:40, Bart wrote:
> 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.
> 

OK.  You are not alone in that.  (Standard C didn't support a difference 
there until C23.)

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

There are irrelevant differences in syntax, which could easily disappear 
entirely if a language supported a default initialisation value when a 
return gives no explicit value.  (i.e., "T foo() { return; }; T x = 
foo();" could be treated in the same way as "T x;" in a static 
initialisation context.)  /Your/ language does not support that, but 
other languages could.

Then you list some things that may or may not happen, which are of 
course totally irrelevant.  If you list the differences between bikes 
and cars, you don't include "some cars are red" and "bikes are unlikely 
to be blue".


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

It's a pointless distinction.  Any function or procedure can be morphed 
into the other form without any difference in the semantic meaning of 
the code, requiring just a bit of re-arrangement at the caller site:

	int foo(int x) { int y = ...; return y; }

	void foo(int * res, int x) { int y = ...; *res = y; }


	void foo(int x) { ... ; return; }

	int foo(int x) { ... ; return 0; }


There is no relevance in the division here, which is why most languages 
don't make a distinction unless they do so simply for syntactic reasons.
	

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

As always, you are trying to make your limited ideas of programming 
languages appear to be correct, universal, obvious or "natural" by 
saying things that you think are flaws in C.  That's not how a 
discussion works, and it is not a way to convince anyone of anything. 
The fact that C does not have a keyword used in the declaration or 
definition of a function does not in any way mean that there is the 
slightest point in your artificial split between "func" and "proc" 
functions.


(It doesn't matter that I too prefer a clear keyword for defining 
functions in a language.)

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

That is solely from your choice of an IL.

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

There are no circumstances where you can use the function correctly and 
it does not return the correct answer.  If you want to consider when 
people to use a function /incorrectly/, then there are no limits to how 
wrong they can be.

> 
>> 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!)
> 

Making the same mistake again does not help your argument.

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

Of course you are wrong!

You have failed to grasp the key concept of programming - it is based on 
contracts and agreements.  Tasks are broken down into subtasks, and for 
each subtask there is a requirement for what gets put into the subtask 
and a requirement for what comes out of it.  The calling task is 
responsible for fulfilling the input requirements, the callee subtask is 
responsible for fulfilling the output requirements.  The caller does not 
need to check that the outputs are correct, and the callee does not need 
to check that the input tasks are correct.  That is the division of 
responsibilities - and doing anything else is, at best, wasted duplicate 
========== REMAINDER OF ARTICLE TRUNCATED ==========