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

[David B. Lamkins]

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.