Re: [Bug-apl] Subtle parsing problem

[Juergen Sauermann]

Hi Elias,

what you propose is i actually exactly what happens under the hood.
When you enter {⍵} 1 then {⍵} triggers the creation of a function λ1:

Z←λ1 ⍵
Z←⍵

and the original {⍵} 1 is being replaced by λ1 1.

The "problem" with niladic functions below is not at all related to lambdas but demanded
by the right to left evaluation in APL. Since niladic functions have no argument the are evaluated
as soon as the run-time parser sees them. Thats why your right lambda is evaluated before the SEL operator,
The reason why the left lambda is evaluated after the SEL is because the phrase containing it, i.e. {...} SEL B
is longer than the niladic lambda {...} alone.

The same would have happened if you had used defined functions or primitive functions instead of lambdas.

So your dream may have come true - except that it maybe turned out to be a nightmare?

/// Jürgen


On 07/29/2014 03:17 PM, Elias Mårtenson wrote:

I agree in part. My opinion is that all of these problems would be solvable if immediate lambdas required an explicit function call to be evaluated. I.e. {⍵} 1 should not evaluate to 1, but rather the function itself and the number one. Then, having a separate symbol to force evaluation.

Sadly, this is not the case, of course,so the above is just me dreaming. :-)

That said, I believe that lambdas should be extended to become more "functional" and generic. This includes lexical closures as well as proper first-class functions. To do so, however, would require first looking at how other APL's do it, as there is no reason to reinvent the wheel. Also, there are more important things to do first. :-)

Regards,
Elias

On 29 Jul 2014 20:48, "Juergen Sauermann" <address@hidden> wrote:

Hi,

I have put the power operator onto my long-term TODO list (aka README-4-compliance), SVN 402.

BTW the somewhat unexpected behavior of your niladic functions comes from the IMHO broken syntax
of the rank operator (which allows values where unaware people would expect functions). Before that
your right lambda would have returned a value and the SEL would have triggered a syntax error.

My concern in the context of lambdas is that if we drive that too far then we would create new cases
that nobody can understand anymore.

/// Jürgen


On 07/29/2014 02:11 PM, Elias Mårtenson wrote:

Hmm, so having a right-hand nildaic function passed to an operator simply doesn't work. Oh well, makes sense once you think about it. :-)

This was all part of experimentation I was playing around with while thinking about the power operator. Have you given that one any thought yet?

Regards,
Elias

On 29 July 2014 19:55, Juergen Sauermann <address@hidden> wrote:

Hi Elias,

this is because your lambdas are niladic. The right lambda is called before SEL,
while the left lambda is called by SEL. From SEL's perspective, 'then'; is a function
while 'else' is a value.

/// Jürgen

On 07/29/2014 07:21 AM, Elias Mårtenson wrote:

I was writing an operator that acts as an "if"-statement, calling one of two functions depending on the value of the argument:

∇Z ← (then SEL else) arg

  →(arg=1)/do¯then

  →(arg=0)/do¯else

  ⎕ES 'Illegal value for arg'

  →0

do¯then:

  Z ← then arg

  →0

do¯else:

  Z ← else arg

∇

Note that the then and else functions are called with an argument "arg". When I call this operator with two nihilic lambda functions, I get very strange behaviour:

      ⊣ ({⎕←'was true'} SEL {⎕←'was false'}) 0

was false

      ⊣ ({⎕←'was true'} SEL {⎕←'was false'}) 1

was false

was true

I would expect to get an error message here, or perhaps seeing (⎕NC '⍵') to be 0. I certainly didn't expect to see both functions be called. My suspicion is that there is a problem with the parser somewhere, but I think Jürgen will have to look at this one.

Regards,

Elias