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):
>
> *EVALUATION OF EXPRESSIONS*
>
> *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*
>  *Lambda*.
>
> 5. Even more interesting, the inventor of the {...} notation (as far as i
> know)
> says (on *tryapl.org <http://tryapl.org>*) the following:
>
> *      Lambda ← { ⎕TS }*
>
> *      )FNS*
> *Lambda*
>
> *      Lambda     ⍝ expecting e.g.  **2023 6 8 19 25 43 139*
> *{⎕TS}  *
>
> which makes, IMHO, even less sense.
>
> Hope this explains it,
>
> Jürgen
>
>
> 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
> )clear
> ⍝ 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
>
> 0
> Spent Time : 2.002
> 0
> Spent time : 0
>
> Why ?
>
> Bonus question : what causes the impression of the 0s ?
>
> Sincerely,
>
> -- Emmanuel Charpentier
>
>
>

Reply via email to