Re: else ladders practice

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.