Re: [Bug-apl] dynamic function not referencing global?

[Juergen Sauermann]

Hi Xtian, as I said, in the niladic case it is the APL syntax and not the fact that a function is defined as lambda which causes this behavior. Therefore local variables have no effect here. If we would change this then niladic lambdas would behave differently than niladic non-lambda functions, which I consider worse than not being able to define named niladic lambdas. And such a syntax would deviate from the standard APL syntax. As a matter of fact, all lambdas (niladic or not) are converted to defined functions of the same valence long before the statement is executed. It is only in immediate execution mode that the niladic function is computed immediately. The same  time←{⎕TS} inside another define function, say FOO, may be computed long after the FOO is ⎕FXed. The conversion of time←{⎕TS} into a niladic defined function called λ1 happens when FOO is ⎕FXed while the resulting time←λ1 happens later when FOO reaches that statement in FOO.  At that later point in time normal vanilla APL execution is taking place, and we do not want to change that, do we? /// Jürgen On 10/26/2016 08:16 PM, Christian Robert wrote: Niladic Lambda can be usefull. I wonder if it could be possible to use some trick to generate niladic Lambda. Like in:       )erase time       time←{⎕TS ;x} Since this lambda has a local variable defined, then it should be a definition and since there is no ⍵ nor ⍺ then it should be niladic one. Only Juergen can say if it is possible, or find an other trick and how hard to implement ... Just some personnal tought. Xtian. On 2016-10-26 06:54, Juergen Sauermann wrote: Hi, correct. To explain why this is so, consider this: *     {1+2}** **3 **      {1+⍵}** **SYNTAX ERROR* *      {1+⍵} 5** **6** * Therefore in *      F0←{1+2}* GNU APL first reduces *{1+2} *to *3* and then assigns *3* to *F0*, making *F0* a variable because a values is being assigned to a name. This is normal APL and holds for all niladic functions and not only for niladic lambdas. In contrast, in *      F1←**{1+⍵} * **{1+⍵}**cannot be reduced (as opposed to *{1+⍵} 5*which can), so it is shifted onto the evaluation stack, then *←* is shifted (still not being able to be reduced), and finally *F1* is shifted. At this point the stack contains the valid phrase *F1←**{1+⍵}*, which can be reduced and causes *F1 *to become a monadic function bound to the name *F1*. /// Jürgen On 10/25/2016 07:01 PM, Christian Robert wrote: DISPLAYhand←{,(⍪hand),' '} this create a variable DISPLAYhand this is because de {} does not contain neither alpha nor omega. Xtian. On 2016-10-25 12:54, alexwei...@alexweiner.com wrote: Hi bug-apl, Why does DISPLAYhand not use the new value of hand on the second call?       deck←''       deck←deck,"🂢" "🂲" "🃂" "🃒"       deck←deck,"🂣" "🂳" "🃃" "🃓"       deck←deck,"🂤" "🂴" "🃄" "🃔"       deck←deck,"🂥" "🂵" "🃅" "🃕"       deck←deck,"🂦" "🂶" "🃆" "🃖"       deck←deck,"🂧" "🂷" "🃇" "🃗"       deck←deck,"🂨" "🂸" "🃈" "🃘"       deck←deck,"🂩" "🂹" "🃉" "🃙"       deck←deck,"🂪" "🂺" "🃊" "🃚"       deck←deck,"🂫" "🂻" "🃋" "🃛"       ⍝deck←deck,"🂬" "🂼" "🃌" "🃜"   ⍝knights       deck←deck,"🂭" "🂽" "🃍" "🃝"       deck←deck,"🂮" "🂾" "🃎" "🃞"       deck←deck,"🂡" "🂱" "🃁" "🃑"       deck ← ⊖13 4 ⍴ deck       hand←(∈deck)[13?52]       DISPLAYhand←{,(⍪hand),' '}       DISPLAYhand 🂢 🃈 🃃 🂷 🃞 🃙 🃝 🂫 🃋 🃕 🃒 🃂 🂧       hand←(∈deck)[13?52]       DISPLAYhand 🂢 🃈 🃃 🂷 🃞 🃙 🃝 🂫 🃋 🃕 🃒 🃂 🂧       hand 🂤🂺🂾🂷🂪🂱🂳🂸🃚🃅🂻🂲🂭 Thanks, Alex