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: Mon, 4 Nov 2024 23:25:32 +0100
Organization: A noiseless patient Spider
Lines: 175
Message-ID: <vgbhkt$155v2$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 04 Nov 2024 23:25:33 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9c2e76ff71a974b5abd108ce38c454d4";
	logging-data="1218530"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+p6JTvQRAkbrqiHJOv2Mik6V3FMPnlc5c="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:LOxTjnHdDKLAjspEdLS6qq4y97s=
In-Reply-To: <vgb8if$13ioj$1@dont-email.me>
Content-Language: en-GB
Bytes: 8267

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

A much more useful distinction would be between Malcolm-functions and 
Malcolm-procedures. "Malcolm-functions" are "__attribute__((const))" in 
gcc terms or "[[unsequenced]]" in C23 terms (don't blame me for the 
names here).  In other words, they have no side-effects and their 
result(s) are based entirely on their inputs.  "Malcolm-procedures" can 
have side-effects and interact with external data.  I would possibly add 
to that "meta-functions" that deal with compile-time information - 
reflection, types, functions, etc.

> 
>> and only need to be "solidified" during code generation.  That might 
>> allow the language to track things like "uninitialised" or "no value" 
>> during compilation without having them part of a real type (such as 
>> std::optional<> or a C 
> 
> But you are always returning an actual type in agreement with the 
> language. That is my point. You're not choosing to just fall off that 
> cliff and return garbage or just crash.
> 
> However, your example with std::optional did just that, despite having 
> that type available.
> 
>> It doesn't return a value.  That is why it is UB to try to use that 
>> non-existent value.
> 
> And why it is so easy to avoid that UB.

I agree.  I think C gets this wrong.  That's why I, and pretty much all 
other C programmers, use a subset of C that disallows falling off the 
end of a function with a non-void return type.  Thus we avoid that UB.

(The only reason it is acceptable syntax in C, AFAIK, is because early 
versions of C had "default int" everywhere - there were no "void" 
functions.)


>> Note that I have not suggested returning garbage values - I have 
>> suggested that a language might support handling "no value" in a 
>> convenient and safe manner.
> 
> But in C it is garbage.

Note that /I/ have not suggested returning garbage values.

I have not said that I think C is defined in a good way here.  You are, 
as so often, mixing up what people say they like with what C does (or 
what you /think/ C does, as you are often wrong).  And as usual you mix 
up people telling you what C does with what people think is a good idea 
in a language.

> 
>> Totally independent of and orthogonal to that, I strongly believe that 
>> there is no point in trying to define behaviour for something that 
>> cannot happen,
> 
> But it could for n==4.

Again, you /completely/ miss the point.

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.

> 
> EVERYBODY agrees that leading zero octals in C were a terrible idea. You 
> can't say it's just me thinks that!

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.


> 
>>>     int F() {
>>>         F(1, 2.3, "four", F,F,F,F(),F(F()));
>>>         F(42);
> 
>> It is undefined behaviour in C.  Programmers are expected to write 
>> sensible code.
> 
> But it would be nice if the language stopped people writing such things, 
> yes?

Sure.  That's why sane programmers use decent tools - the language might 
not stop them writing this, but the tools do.

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


> 
> None? So it's not just me and my language then! Mine is lower level and 
> still plenty unsafe, but it has somewhat higher standards.
> 
>> If I were the designer of the C language and the maintainer of the C 
>> standards, you might have a point.  C is not /my/ language.
> 
> You do like to defend it though.

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.

> 
> 
>> We can agree that C /lets/ people write messy code.  It does not 
>> /require/ it.  And I have never found a programming language that 
>> stops people writing messy code.
> 
> I had included half a dozen points that made C's 'if' error prone and 
> confusing, that would not occur in my syntax because it is better designed.
> 

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

> You seem to be incapable of drawing a line beween what a language can 
> enforce, and what a programmer is free to express.
> 

I can't see how you could reach that conclusion.

> Or rather, because a programmer has so much freedom anyway, let's not 
> bother with any lines at all! Just have a language that simply doesn't 
> care.
> 

You /do/ understand that I use top-quality tools with carefully chosen 
========== REMAINDER OF ARTICLE TRUNCATED ==========