Russ Lewis wrote:
> On the same project I mentioned in my previous message, I declared a function which I was only going to call in one spot.  I had to name it (see prev msg), but I would have preferred to not name it.
> 
> So this syntax would have been correct (though unreadable):
>     DoStuff(function char[](ulong) {...} (<argument>)));
> 
> Does anybody have a good idea for some sort of syntax that would allow you to define an unnamed function and then immediately call it?  I couldn't write a simple expression because it required recursion (or looping, if you prefer).

I'll offer two ideas, which I considered and didn't like, followed by an idea that I stumbled upon today which I like:

Bad: use <arg> = <value>
	function char[](ulong arg = 1234) {...}
bad because it looks like a default argument

Bad: use <arg> : <value>
	function char[](ulong arg : 1234) {...}
I just don't like the looks of it.



What I like:  function <retType>(<args>)(<values>)
	function char[](ulong arg)(1234) {...}



The advantage here is that the arguments are right there at the front. So it's readable for people who are familiar with the construct, but I can't necessarily say that it is inherently readable for newbies. That's certainly a downside. :(

Thoughts?

Manfred Nowak wrote:
>
> You seems to know, that it is easy to bash examples instead of
> recognizing the analogies. So what is in your opinion in the
> "mindspace"-view the difference between a function body and a
> huge expression on the RHS of a `=' symbol?

In my opinion not much difference at all. Anonymous variables can be useful but they can also be overused.


> Your argument is, that the "mindspace" of main is less
> cluttered. This is not necessarily true because it depends on
> the psychological habits of the reader.

> But it is undoubtly true, that the "mindspace" of the module
> containig `main' is cluttered temporarily with an unresolved
> reference to `main_aux' and then constantly contaminated with
> the resolved reference to `main_aux'.

> I.e. using function/auxiliary function pairs exhaust the human
> short time memory chunks with doubled speed.

Here is something that illustrates this issue. Pay close attention because normally this is spoken so if you have to go back and read anything you had to cheat.
----------------------------------------------------------------
Bob is driving a bus with 15 passengers. At the first stop 3 people get off and 5 people get on. At the next stop nobody gets off and one person gets on. At the next stop half the people get off and one person gets on. For each of the next three stops the same odd number of people get off at each stop. At the next stop three people get off and nobody gets on.
----------------------------------------------------------------

You should be able to answer a question without reading it again. The question is "What was the name of the bus driver?" I know before you read this sentence you will have inadvertantly glanced back up to see what the name was even though I said it was strictly forbidden.

If your argument was correct then the "mindspace" of that whole exercise should have been "constantly contaminated" by the name Bob. However it was not. The format suggest - screams even - that I will soon be asking you how many people are on the bus and you quickly realize 'Bob' has nothing to do with anything and tosses it out to make room for the important things.


> Furthermore the contamination of the "mindspace" may lead to
> hardly detectable errors as you can see if you extend your
> example above with another pair of functions:
>
> <code>
> ... // as above
>
> void mainn(){
>   printf( "%d\n", main_aux(20) );
> }
>
> int mainn_aux(int i) { return i^2; }
> </code>
>
> Are you recognizing, that the body of `mainn' is contaminated
> from the beginning with a reference to `main_aux'?

If 'main_aux' causes any trouble at all then it is a trifle compared to 'main' itself. The biggest question in the readers mind would be why 'main' and 'mainn' however the answer to why 'main_aux' and 'mainn_aux' will be self evident - they are simply there because of the troublesome 'main' and 'mainn'.

This is my last post to this branch.

parabolis wrote:

[...]
> Anonymous variables can be useful but they can also be overused.

Agreed. And therefore the decision is up to the writer.

[...]
> Bob is driving a bus with 15 passengers. At the first stop 3
[...]
>'Bob' has nothing to do with anything and tosses
> it out to make room for the important things.

As I already mentioned the actions depend on the psychological habits. And you are wrong with the expectations of my habits in this area.

I know this example very well, stopped reading when recognizing "bus" and rushed to the question to examine if it is really the question for the name of the driver ... bingo.

However, your example shows, that programmers are used to solve difficulties, because it describes the typical body of a function returning a non-void type: to understand it, you have to look at the expression attached to the return statement first, which is usually at the end of the body and then read through the body to understand how the terms of that expression are built.

Following your example, the `return' should be dropped in favour for a predefined variable `result' whose type is equal to the type of the return value of the function. There were discussions about this issue.

[...]
> > Are you recognizing, that the body of `mainn' is contaminated from the beginning with a reference to `main_aux'?
[...]
> they are simply there because of the troublesome 'main' and 'mainn'.

Please stop bashing examples: even if you replace `mainn' by a name as different from `main' as you want, the wrong call of `main_aux' cannot be detected by the compiler. So with that contamination you are living at an  unnecessary risk.

Furthermore your technic is applicable at the module level only: nested functions must precede the scope in which they are called.

-manfred

What intrigues me is the length of this thread.

A similar one could have been about naming "throwaway" variables. No one has a problem with i, j, etc. Then why not just use f, g, etc. for such throwaway functions.

There's even no problem with the scarcity of names (f,g,h), because by the time you need i,j and so on, you'd better rename all these to something meaningful anyway.