Re: else ladders practice

On 06/11/2024 20:38, Bart wrote:

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?
 

It would not necessarily mean all zeros, but yes, that's the idea.  You could easily say that returning from a non-void function without an explicit value, or falling off the end of it, returned the default value for the type in the same sense as you can have a default initialisation of non-stack objects in a language.  (In C, this pretty much always means all zeros - in a more advanced language with object support, it would typically mean default construction.)
Equally, you could say that in a void function, "return x;" simply casts "x" to void - just like writing "x;" as a statement does.
I'm not suggesting that either of these things are a particularly good idea - I am merely saying that with a minor syntactic change to the language (your language, C, or anything similar) most of the rest of the differences between your "proc" and your "func" disappear.
All you are left with is that "func" can be used in an expression, and "proc" cannot.  For me, that is not sufficient reason to distinguish them as concepts.

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

Sure.  As I say, I don't think it is a particularly good idea - at least, not as an addition to C (or, presumably, your language).

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

Of course.  (Theoretically in C, pointers are initialised to null pointers which don't have to be all zeros.  But I don't know of any implementation which has something different.)  I was just using that to show how some languages - like C - have a default value available.

 

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.
 

There's a difference between cars and bikes - not between procs and funcs.
Remember, if you are going to make such a distinction between two concepts, it has to be absolute - "likely" or "unlikely" does not help. You can't distinguish between your procs and funcs by looking at the existence of side-effects, since a code block that has side-effects might return a value or might not.  It's like looking at a vehicle and seeing that it is red - it won't tell you if it is a bike or a car.
This is why I say distinguishing between "func" and "proc" by your criteria - the existence or absence of a return type - gives no useful information to the programmer or the compiler that can't be equally well given by writing a return type of "void".

But I guess you find those likely/unlikely macros of gcc pointless too.

How is that even remotely relevant to the discussion?  (Not that gcc has macros by those names.)

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.

That's useless information - both to the programmer, and to the compiler.  (I am never sure which viewpoint you are taking - it would be helpful if you were clear there.)  If the compiler /knows/ global state cannot be changed, and the function only uses data from its input values, then it can do a lot with that information - shuffling around calls, removing duplicates, pre-calculating constant data at compile time, or whatever.  Similarly, if the programmer /knows/ global state cannot be changed in a function, then that can make it easier to understand what is going on in the code, or what is going wrong in it.
But if you only know that it is /likely/ to be one thing or the other, you know nothing of use.

 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.
 

I can have a go at you for not thinking!  I believe that if you think more carefully about this, you will understand how little your distinction helps anyone.  You might find the distinction I made - between being allowed to interact with global state (a "procedure") and having no possibility of interacting with global state (a "function") - to be useful.  In my distinction, there is no grey area of "likely" or "unlikely" - it is absolute, and therefore gives potentially useful information.  Of course it is then up to you to decide if it is worth the effort or not.
Let me tempt you with this - whatever syntax or terms you use here, you'll be able to brag that it is nicer than C23's "[[unsequenced]]" attribute for pure functions!

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

Why?  Once you've put it in the language, there is no motivation to drop it.  Pascal has the same procedure / function distinction you do.  Just because it adds little of use to language, does not mean that you'd want to drop it and make your tools incompatible between language versions.

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?

Returning something from a function by returning a value, or by having the caller pass a pointer (or mutable reference, if you prefer that term) and having the function pass its results via that pointer are not really very different.  Sure, there are details of the syntax and the ABI that will differ, but not the meaning of the code.
Remember that this is precisely what C compilers do when returning a struct that is too big to fit neatly in a register or two - the caller makes space for the return struct on the stack and passes a pointer to it as a hidden parameter to the function.  The function has no normal return value.  And yet the struct return is syntactically and semantically identical whether it is returned in registers or via a hidden pointer.

 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?
 

Maybe not, if you can't understand /why/ I am dismissing them.  The only difference you listed that is real and has potential consequences for people using the language is that functions returning a value can be used in expressions - all the rest is minor detail or wishy-washy "maybes".

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.
 

If it ultimately comes down to just the word you want to use, then I guess that's fair enough.  It is the /reasoning/ you gave that I am arguing with.
If your language has "do ... until" and "do ... while" loops, and you justify it by saying you simply find it nicer to write some tests as positives and some tests as negatives, then I think that is reasonable. If you claim it is because they are fundamentally distinct and do different things because one is likely to loop more than three times and the other is unlikely to do so, then I'd argue against that claim.

 

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.
 

I quite agree that your syntax is clearer that the example in C for this kind of thing.  I rarely see the C syntax as complicated - for my own code - because I use typedefs and spacing that makes it clear.  But I fully agree that it is clearer in a language if it distinguishes better between declarations of variables and declarations of functions.
However, I don't think it would make a huge difference to the clarity of your syntax if you had written :
func F -> void
ref void G
ref func H -> void
func I -> ref void
or
func F
ref void G
ref func H
func I -> ref void
It is not the use of a keyword for functions that I disagree with, nor am I arguing for C's syntax or against your use of "ref" or ordering.  I simply don't think there is much to be gained by using "proc F" instead of "func F -> void" (assuming that's the right syntax) - or just "func F".
But I think there is quite a bit to be gained if the func/proc distinction told us something useful and new, rather than just the existence or lack of a return type.

 

>
(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?
 

Yes, they can.  But it would be nicer with a keyword.  Where possible, I prefer clear language constructs /and/ nice syntax highlighting and indexing from tools.  Call me greedy if you like!

 

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?
 

I can agree with you about some of the things you say about C, while still disagreeing with other things (about C or programming in general).

 

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

You /do/ whine a lot.  But here I was asking, rhetorically, if you thought that was a good alternative to finding ways to make C work well for me.

 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.

I haven't been berating or belittling your language here - I have been arguing against some of the justification you have for some design decisions, and suggesting something that I think would be better.

 

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?

 Plenty of companies use DSLs. But isn't that sort of what you do? That is, using 'C' with a particular interpretation or enforcement of the rules, which needs to go in hand with a particular compiler, version, sets of options and assorted makefiles.
 

No.

I for one would never be able to build one of your programs. It might as well be written in your inhouse language with proprietory tools.
 

Pretty much every professional in my field could manage it.  But software development is a wide discipline, with many niche areas.