(note: this email become longer than expected, I tried to summarise in the
end. Sorry for making you spend time reading this, I suppose I feel this
subject to be quite important)
Not quite. What's being argued is that there is no such thing as a niladic
lambda at all. At least that's what I'm arguing. :-)
Niladic lambdas are confusing no matter how one goes about implementing
them. The fundamental example would be:
* foo ← {1 ⊣ ⎕←'hello'}*
Should calling foo result in 'hello' being printed?
Currently, in GNU APL, 'hello' is printed when assignment happens, and bar
gets assigned the value 1 as a variable (i.e. bar is not a function). Given
the current implementation, there would be two major differences, both of
them being significant improvements, along with a side effect that is, I
suppose, what this entire debate hinges on:
- Since niladic lambdas are not treated specially any more, the example
above would result in foo becoming a function and 'hello' would be printed
when being called.
- Lambdas that do not specify a ⍵ can now be used as operator arguments.
And the side effect:
- Lambda assignment can't be used to define niladic functions. But
lambda assignment can't be used to define niladic functions *anyway* since
the lambda gets evaluated before the assignment. Changing this will
introduce *more* confusion, not less since it would break the assumption
that evaluation happens from the right.
It would of course also result in a change of behaviour of directly
evaluated lambdas, such as this:
1 2 3 {10} 4 5 6
Which currently evaluates to:
1 2 3 10 4 5 6
But after the change would become (and inline with what Dyalog does):
10
That said, such evaluations are bordering on useless anyway. No one would
use direct evaluation of niladic lambdas in practice.
*In summary,*
Niladic lambdas can conceivably be used in three ways:
1. Assignment to a name
2. Direct evaluation
3. Argument to operator
The reason I consider the current implementation really bad is because:
1. Can't be done, since the value is evaluated before assignment
(changing this would break right-evaluation rules as mentioned above)
2. Pretty much useless. Not needed, so its behaviour doesn't matter much.
3. Doesn't work.
Using the current proposal, however:
1. Works. The resulting function is monadic/dyadic
2. Behaviour changed, but still just as useless
3. Works
I suppose that I just can't see how the current behaviour can be considered
better by reasonable measure.
Regards,
Elias
On 7 August 2014 22:12, Juergen Sauermann <[email protected]>
wrote:
> Hi,
>
> my point is that there should be no difference between lambdas and defined
> functions.
>
> The reason that the left argument is ignored is that dyadic functions can
> be called monadically
> (the presence of the left argument *can* be checked with *⎕NC* but it
> does not have to be checked.)
> But even in this case lambdas and defined functions behave in the the same
> way.
>
> What you are arguing for is that lambdas and defined functions shall
> behave differently
> in the niladic case. This maybe convenient at times but would increase the
> complexity
> of the syntax and could come as a surprise for many others
>
> /// Jürgen
>
>
>
> On 08/07/2014 03:58 PM, Jay Foad wrote:
>
> Right. Even in GNU APL monadic lambdas consume and ignore any left
> argument you give them, so you could argue that it's consistent for
> niladic lambdas to consume and ignore both arguments.
>
> Jay.
>
> On 7 August 2014 14:53, Elias Mårtenson <[email protected]>
> <[email protected]> wrote:
>
> And, one could argue that knowing that lambdas are always variadic is quite
> consistent in itself.
>
>
>
