[Top][All Lists]

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

Re: Niladic functions vs niladic lambdas

From: Emmanuel Charpentier
Subject: Re: Niladic functions vs niladic lambdas
Date: Wed, 14 Jun 2023 21:47:33 +0200
User-agent: Evolution 3.46.4-2

[ Copy of my answer to Elias, which somehown didn't make it to bug-apl... ]

Dear list,

thank you all for your answers, which help me seriously in my discovery of APL ... 40 years after !

Emmanuel Charpentier

Le vendredi 09 juin 2023 à 02:04 +0800, Elias Mårtenson a écrit :
You note an inconsistency, but the problem isn't worth the lambda syntax but rather with assignment. In the lambda syntax of Dyalog, the left arrow are used both to assign functions as well as values, which makes the evaluation rules complicated.

I came across the same problem when I implemented it in KAP. In my case it was even worse since KAP always parses from left to right and generated a syntax tree before evaluation, so the ad hoc person of Dyalog is even more ugly.

I chose to use a different symbol for assigning to functions. I use ⇐ instead of ← of this purpose. It turned out to work pretty well.

Den fre 9 juni 2023 01:44Dr. Jürgen Sauermann <mail@jürgen-sauermann.de> skrev:
Hi Emmanuel,

first of all, lambdas are a bad construct which causes quite
a number of syntactic inconsistencies. Simply speaking,
the concept has not been thought out well.

1. A defined function created with ∇ or ⎕FX is unambiguously
 that: a defined function. For that reason I sometimes call
them "proper functions"  (as opposed to lambdas which are
anything but proper).

2. The stone-old fundamental APL evaluation rule reads (quote
from the IBM APL2 Language Reference Manual, page 20):


All functions execute according to their position within an _expression_. The rightmost
function whose arguments are available is evaluated first.

3. Now look at, for a simple example:

      Lambda ← { ⎕TS }

According 2. above (and noting all functions, which certainly includes the
special case of niladic functions), the niladic { ⎕TS } is the rightmost
function whose arguments (i.e. none since the { ... } is niladic) has to be
computed first.As of this writing, the result is, say,

      { ⎕TS }
2023 6 8 19 25 43 139

and what remains is:

      Lambda ← 2023 6 8 19 25 43 139

4. IOW: what looks at the first glance like the definition of a niladic function
named Lambda is actually the assignment of  a 7-item vector to variable

5. Even more interesting, the inventor of the {...} notation (as far as i know)
says (on tryapl.org) the following:

      Lambda ← { ⎕TS }


      Lambda     ⍝ expecting e.g. 
2023 6 8 19 25 43 139

which makes, IMHO, even less sense.

Hope this explains it,


On 6/8/23 17:37, Emmanuel Charpentier wrote:

Dear list,

It seems that niladic lambdas are treated like constants.

Rough and naïve illustration : pasting this :

⍝ What about niladic functions and lambdas ?
⍝ Example of a numeric timestamp generator
⍝ Simplifying assumptions : we want to measure about a few minutes
⍝ and not around midnight...
⍝ Start afresh
⍝ Function
∇ R ← NTS
  R ← 24 60 60 1000 ⊥ ¯4↑⎕TS
⍝ Try it
T1 ← NTS
⍝ Wait a few seconds
)host sleep 2
T2 ← NTS
⍞←'Spent Time : ',⍕(T2-T1)÷1000
⍝ Lambda
nts ← {24 60 60 1000 ⊥ ¯4↑⎕TS}
⍝ Try it
t1 ← nts
⍝ Wait a few seconds
)host sleep 2
t2 ← nts
⍞←'Spent time : ',⍕(t2-t1)÷1000

in a gnu-apl buffer gives :

      CLEAR WS

Spent Time : 2.002
Spent time : 0

Why ?

Bonus question : what causes the impression of the 0s ?


-- Emmanuel Charpentier

reply via email to

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