Re: else ladders practice

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