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, 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←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
|