I was wondering if it is really necessary to provide the function arguments in uni's linq example both with the right names in the inline assignmants and with the right position in the argument list. And in fact, sometimes you really can mix the order. However, this does not work always and I am not able to find an explanation, when this works and when it does not. Another issue which adds complexity is the question, which of the inline definitions is visible outside.

This provides limitless options to hide your design intent from uninitiated outsiders.

---

I suppose most of us remained puzzled now
As you said - s... happens

To be honest, I myself am very surprised that never crossed my mind to try putting some inline assignment in the function call.

Although there might be some logic here, I find it rather confusing and hard to follow

Regards,
Radovan

---

Maybe it's like this: first step is assigning all formal variables their symbolic values by place, then evaluate all symbolic values from left to right, executing all side-effects (possibly overwriting previously calculated params when name is reassigned):

f(x:=10; z:=20; y:=3)
=step 1=> x->x:=10; y->z:=20; z->y:=3
=step 2=> x=
=step 3=> y= - here y is 20, AND z is 20
=step 4=> z= - here z is 3, AND y is 3!

This explains all Radovan's samples, but not Martin's. Here's why.

select(`(x):=x^2;`v:=(1..4))
=step 1=> `v->`(x):=x^2; `->`v:=(1..4)
=step 2=> `v= - here TWO functions are created: `(x) AND `v(x)! - EDIT: not true. Only one function `(x)=x^2, and one variable `v=x^2.
=step 3=> `= - here TWO vector variables are created: `v AND `! So, TWO entities names ` coexist at this time: a function and a variable.
smath allows having many entities of same name: a variable and a number of functions having different number of args (overloading).
In select, then, only vector `v and function `(x) are used.

f:=(f(x):=x^2)
f(2)=4
f=error: x - not defined
x:=3
f=9

Note that here two entities are defined: a function f(x)=x^2, and a scalar variable f=x^2. I believe that uni's approach to use ` as a lambda name creates the same effect: in his functions, there always exist a variable named ` (that is never used), and when this argument is assigned "lambda" like '(x):=x^2, this creates another function-local (?) entity (function) named `(x), that uni uses.
And that means that uni could use just any name for the formal arg there, but only require that lambda be named `, like here:

[MATH lang=eng]x:3[/MATH]

[MATH]f(a;b):line(trace(a);`(b);2;1)[/MATH]

[MATH]f(`(x):x^2;2)=4[/MATH]

(note that I must use ` in second line, while the formal arg is names a)
NB: trace output: a = 9!

I imagine what effects could this techinque introduce by changing some names used by function internally...

Very interesting things you wrote here, guys. I want only to say what I choosed ` symbol because in this case the equation has view which is similiar to original lamdba definition: (x) => x^2. And we have `(x) := x^2. Nothing else.

EDIT: As for the local vars. In first version I used _, but I changed it to ` because this likes me more. Usually you use _x for locals, but I used `x for short.
EDIT2: (x) => ... - must be an implicit function and when we write `(x) := ... it looks like a function without name ( "implicit" ).

Thank you all for your explanations. The explanations by Mike seem to be consistent with the observed return values. The side effects might be consistent with output parameter handling, once you see everything but step 1 in Mike's explanations as part of the function body. But I did not yet verify that.

My impression is that we need a function call syntax without any name restrictions. If at a certain position a function is expected, any pre-defined or inline-assigned function of any or without name should do. Formal parameter names must be strictly shielded from global namespace.

Wrote

If at a certain position a function is expected, any pre-defined or inline-assigned function of any or without name should do.

Note that function as parameter is another syntax: f(g(2)...):=... or f(g(a;b;c)...):=... where a, b and c are uninitialized at the time of definition. It's covered here.

That approach is somewhat limited, I'd say it's not ready for prime-time yet, that's why this uni's technique is required (and invaluable to workaround, say, SS-123).

Here is an attempt to summarize part of the discussion. Not yet covered:
- analysis of what happens if there are name coincidences in the function call and in the list of the formal parameters, including effects of evaluation order
- side effects of inline definitions
- and much more...

---

Section Prog functions as arguments.sm (21 KiB) downloaded 60 time(s).