Re: [Bug-apl] Yet another lambda proposal...

[Louis de Forcrand]

Dyalog lambdas aren’t that different from GNU ones AFAIK. Minor differences include

use of the statement separator in Dyalog’s, which can be circumvented with stop,

and local / global variables (disregarding multi-lines and case statements, etc).

Nested lambdas can be used in GNU APL as well.

Most of the time one can copy-paste a one-liner Dyalog lambda to GNU APL without

a problem if it uses only ISO functions, e.g. no currying or keys.

Curly braces could be replaced with something else to differentiate GNU lambdas from

other lambdas.

But I am against using brackets if that would mean no bracket indexing in lambdas. I rarely

use squad other than to index at top level because of its terrible (IMHO) syntax. Everything

you can do with squad can be done with bracket indexing, without using rank and other clutter

(except that one must know the rank of what is being indexed to use bracket indexing; I’ll give

squad that).

I would stick with curly braces (or at least stay away from brackets); however using an

explicit result could allow for things normally only available in del functions to be used in

lambdas, and make lambdas more similar to del fns. This could be an interesting idea:

{B←+/λ←…}

That would return λ but store its sum in global var B. Although this could be achieved

today as:

{T⊣B←∨/T←…}

In any case, that and Jürgen’s idea for local / global vars would be enough to distinguish a

GNU lambda from a Dyalog one.

Louis

On 14 Aug 2016, at 23:15, David B. Lamkins <address@hidden> wrote:

I've been following the lambda discussion with some interest, and would like to propose yet another alternative for your consideration.

In brief, let's eliminate possible confusion with Dyalog's lambda implementation by adopting a syntax which clearly differentiates GNU APL's lambdas from Dyalog lambdas.

Dyalog lambdas have features which will not be reproduced in GNU APL, most notably multiple lines, guards, nested lambdas and lexical variables.

So rather than having something that looks similar to Dyalog lambdas but isn't, how about using a different syntax...?

The basic form of a GNU APL lambda, apart from the enclosing decoration, is simply an _expression_ that assigns a result to <lambda>.

It's the enclosing decoration, the { }, that confuses APL programmers who've been exposed to Dyalog lambdas. So let's not use { }...

I'd suggest that because [ ] is already an outlier in the APL syntax rules, it'd make sense to extend this outlier syntax for lambdas. The canonical form of a lambda would become:

'[' <lambda> <assign> <_expression_> ']'

You can easily disambiguate this from array indexing by noticing '[' <lambda>, which can't occur in an array index.

The distinctive syntax will serve to inform the reader that this is in fact a GNU APL lambda and not a Dyalog lambda.

Aside from the parsing change, we'd need to add <lambda> to existing keyboard layouts. Perhaps as Alt+q or r or s or f or z for their proximity to the <alpha>s and <omega>s (on US keyboards; maybe the choice'd be narrowed by considering keyboard layouts in other countries) or as Alt+g to associate <lambda> with <nabla> for defining different kinds of functions...

In theory, you could allow traditional APL indexing inside the lambda, but I'd suggest that - for ease of reading - a lambda should disallow bracketed array indices; use <squad> instead.

Obviously you could extend this syntax to allow variable localization. I think that the form '[' <lambda> <assign> <_expression_> [ ';' <name> ] ... ']' would read more naturally, but that's a minor point.

Personally I'd like to see lambdas behave as pure functions, without access to variables outside the lexical scope of the lambda. If you need control over variable scope, write a traditional function.