[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Christian Robert
Subject: Re: [Bug-apl] dynamic function not referencing global?
Date: Wed, 26 Oct 2016 15:27:50 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

On 2016-10-26 15:04, Juergen Sauermann wrote:
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 
of the same valence long before the statement is executed. It is only in 
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 *⎕FX*ed. The conversion of *time←{⎕TS**}* into a niladic 
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 
normal vanilla APL execution is taking place, and we do not want to change 
that, do we?

No, we don't want that !


/// 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.


On 2016-10-26 06:54, Juergen Sauermann wrote:

correct. To explain why this is so, consider this:

*     {1+2}**

**      {1+⍵}**

*      {1+⍵} 5**
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 
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.


On 2016-10-25 12:54, address@hidden 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,"🂬" "🂼" "🃌" "🃜"   ⍝knights
      deck←deck,"🂭" "🂽" "🃍" "🃝"
      deck←deck,"🂮" "🂾" "🃎" "🃞"
      deck←deck,"🂡" "🂱" "🃁" "🃑"
      deck ← ⊖13 4 ⍴ deck

      DISPLAYhand←{,(⍪hand),' '}

🂢 🃈 🃃 🂷 🃞 🃙 🃝 🂫 🃋 🃕 🃒 🃂 🂧
🂢 🃈 🃃 🂷 🃞 🃙 🃝 🂫 🃋 🃕 🃒 🃂 🂧


reply via email to

[Prev in Thread] Current Thread [Next in Thread]