Re: else ladders practice

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 effort.
You are right that C has its flaws - every language does.  I agree with you in many cases where you think C has poor design choices.
But can you not understand that repeating things that you dislike about C - things we have all heard countless times - does not excuse your tunnel vision about programming concepts or change your misunderstandings?

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.
 

It is syntactically legal, but semantically undefined behaviour (look it up in the C standards).  That means it is wrong, but the language standards don't insist that compilers diagnose it as an error.

 

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.

Have you ever played Go ?  It is a game with very simple rules, and extraordinarily complicated gameplay.
Compared to most general purpose languages, C /is/ small and simple. But that is a relative rating, not an absolute rating.

 

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.

Yes.
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?  Make my own personal language that is useless to everyone else and holds my customers to ransom by being the only person that can work with their code?  Perhaps that is fine for the type of customers you have, but not for my customers.
I /do/ understand that C has its flaws (from /my/ viewpoint, for /my/ needs).  So I work around those.

 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 haven't fixed a thing.
(I'm not claiming /I/ have fixed anything either.)

 

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.
 

What a weird thing to guess.

With me it's mostly about the language.
 

An even weirder thing to say from someone who made his own tools.