[Top][All Lists]

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

Re: [Bug-apl] D-fn binding leackage, Nested d-fns

From: Juergen Sauermann
Subject: Re: [Bug-apl] D-fn binding leackage, Nested d-fns
Date: Mon, 03 Mar 2014 15:56:11 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130330 Thunderbird/17.0.5


I have added my first shot at recursive lambdas. SVN 153.

/// Jürgen

On 03/03/2014 02:01 PM, Elias Mårtenson wrote:
I would like to suggest that the most convincing example is that of consistency. If { } can be used to wrap arbitrary APL code in an anonymous function, then it makes sense that you can also nest them.
I'd also like to present my previous email as an example to a situation where I wanted nested lambdas.


On 3 March 2014 20:13, Juergen Sauermann <address@hidden> wrote:
Hello Daniel,

I would like to explain my point of view regarding Lambdas aka. D-funs.

Initially I considered them as not needed; they are not defined in the APL
standard and the rules related to them seem to be rather unclear.

After seeing some requests to support them I started thinking about this
and I figured that they could be somewhat elegant in particular when
used with the EACH operator.

There are still things related to lambdas that I don't like at all because I
believe that they obscure the APL language more than they help.

For example, IMHO the following is definitely unfortunate (even though
possibly convenient and supported in some APL interpreters):

- having different binding rules in lambdas than in normal APL functions,
- "guards" like :IF in lambdas
- probably more...

Nested lambdas are sort of on the border - I could look into this if you
have a convincing example. A good specification of lambdas would also help.
In the meantime you can work around this by eg:

A←{⍵} ◊ {⍵+A 1}1

In GNU APL lambdas create normal user-defined functions and normally follow
their rules. That's why x becomes visible in your example, and IMHO this makes
more sense than hiding x in lambdas but not in user-defined functions.

/// Jürgen

On 03/02/2014 11:53 AM, Daniel H. Leidisch wrote:

Bindings from inside d-fns/lambdas leak into the global environment:


I didn't read much about this, but as far as I understand, bindings
introduced in these functions are supposed to be lexical locals. Anyway,
this doesn't happen in NARS2000, Dyalog and NGN.


On 03/02/2014 11:56 AM, Daniel H. Leidisch wrote:

Nesting d-fns doesn't seem to work:


This works in NARS2000, NGN and Daylog. I'm at r148.



reply via email to

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