[Top][All Lists]

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

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

From: Louis de Forcrand
Subject: Re: [Bug-apl] Yet another lambda proposal...
Date: Mon, 15 Aug 2016 00:26:05 -0400

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:


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


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.


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.

reply via email to

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