Re: [Bug-apl] This looks wrong

[Elias Mårtenson]

(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 <address@hidden> 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 <address@hidden> wrote:

And, one could argue that knowing that lambdas are always variadic is quite
consistent in itself.