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 19:38:09 +0000
Organization: A noiseless patient Spider
Lines: 176
Message-ID: <vgggj2$28fqj$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> <vgg337$26880$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 20:38:10 +0100 (CET)
Injection-Info: dont-email.me; posting-host="425dce3b00381c91a014107c93c4293b";
	logging-data="2375507"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+kghkOWgNZcuHBKz6UEeqk"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ksvK6GmyNuzf6buBdz2oflLktyw=
In-Reply-To: <vgg337$26880$1@dont-email.me>
Content-Language: en-GB
Bytes: 8414

On 06/11/2024 15:47, David Brown wrote:
> On 06/11/2024 15:40, Bart wrote:

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

You wrote:

   T foo () {return;}        # definition?

   T x = foo();              # call?

I'm not quite sure what you're saying here. That a missing return value 
in non-void function would default to all-zeros?

Maybe. A rather pointless feature just to avoid writing '0', and which 
now introduces a new opportunity for a silent error (accidentally 
forgetting a return value).

It's not quite the same as a static initialisiation, which is zeroed 
when a program starts.


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

Yes; if you're using a vehicle, or planning a journey or any related 
thing, it helps to remember if it's a bike or a car! At least here you 
acknowledge the difference.

But I guess you find those likely/unlikely macros of gcc pointless too. 
If I know something is a procedure, then I also know it is likely to 
change global state, that I might need to deal with a return value, and 
a bunch of other stuff.

Boldly separating the two with either FUNC or PROC denotations I find 
helps tremendously. YM-obviously-V, but you can't have a go at me for my 
view.

If I really found it a waste of time, the distinction would have been 
dropped decades ago.

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

As I said, you like to mix things up. You disagreed. I'm not surprised.

Here you've demonstrated how a function that returns results by value 
can be turned into a procedure that returns a result by reference.

So now, by-value and by-reference are the same thing?

I listed seven practical points of difference between functions and 
procedures, and above is an eighth point, but you just dismissing them. 
Is there any point in this?

I do like taking what some think as a single feature and having 
dedicated versions, because I find it helpful.

That includes functions, loops, control flow and selections.


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


   void F();
   void (*G);
   void *H();
   void (*I)();

OK, 4 things declared here. Are they procedures, functions, variables, 
or pointers to functions? (I avoided using a typedef in place of 'void' 
to make things easier.)

I /think/ they are as follows: procedure, pointer variable, function 
(returning void*), and pointer to a procedure. But I had to work at it, 
even though the examples are very simple.

I don't know about you, but I prefer syntax like this:

    proc F
    ref void G
    ref proc H
    func I -> ref void

Now come on, scream at again for prefering a nice syntax for 
programming, one which just tells me at a glance what it means without 
having to work it out.


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

Why? Don't your smart tools tell you all that anyway?


> That is solely from your choice of an IL.

The IL design also falls into place from the natural way these things 
have to work.

> Of course you are wrong!

You keep saying that. But then you also keep saying, from time to time, 
that you agree that something in C was a bad idea. So I'm still wrong 
when calling out the same thing?


> 
> If there was an alternative language that I thought would be better for 
> the tasks I have, I'd use that.  (Actually, a subset of C++ is often 
> better, so I use that when I can.)
> 
> What do you think I should do instead?  Whine in newsgroups to people 
> that don't write language standards (for C or anything else) and don't 
> make compilers? 

What makes you think I'm whining? The thread opened up a discussion 
about multi-way selections, and it got into how it could be done with 
features from other languages.

I gave some examples from mine, as I'm very familiar with that, and it 
uses simple features that are easy to grasp and appreciate. You could 
have done the same from ones you know.

But you just hate the idea that I have my own language to draw on, whose 
syntax is very sweet ('serious' languages hate such syntax for some 
reason, and is usually relegated to scripting languages.)

I guess then you just have to belittle and insult me, my languages and 
my views at every opporunity.

> Make my own personal language that is useless to 
> everyone else and holds my customers to ransom by being the only person 
========== REMAINDER OF ARTICLE TRUNCATED ==========