Programming Language Design and Implementation Stack Exchange is a question and answer site for designers and implementers of computer programming languages. It only takes a minute to sign up.
Sign up to join this community
A lot of languages have anonymous functions, also known as lambda functions. Anonymous, in-line, functions that can be used inside expressions for things like mapping and filtering.
What are common syntax options for lambdas, and what are their pros and cons?
Welcome to the kitchen sink of lambda syntax! All of the following are valid in Scala and produce an anonymous function which adds one to its argument.
x => x + 1
(x: Int) => x + 1
{ x => x + 1 }
{ x: Int => x + 1 }
_ + 1
1.+ and 1.+(_), since + is simply a method on Ints
$\endgroup$
If you haven’t seen it yet, let me introduce you to https://fuckingclosuresyntax.com.
More seriously, the full syntax is this:
{ [byValueCapture] (argName: ArgType) -> ReturnType in body }
…but most of that is optional.
A few things to note:
-> are optional if the type checker can infer it, but must be together; you can’t have one without the other.$0 for the first argument, $1 for the second argument, and so on.in (it’s all implied or unnecessary), that word must be omitted, too.There’s also a shorthand for property access known as a key-path expression; these expressions are equivalent1:
{ (x: MyClass) in x.foo }
\MyClass.foo
\.foo // when the argument type can be inferred
This can lead to some nice abbreviations, such as:
let names = people.map(\.name)
Key-path expressions even support optional chaining, so \.output.first?.substring is valid and equivalent to { $0.output.first?.substring }.
Of course, the wide variation in everything causes some confusion, hence the existence of the aforementioned website.
1 Save for compiler oddities.
\a b -> expr
Advantages:
\ symbol is a mnemonic for λDisadvantages:
map \a b -> c d were legal syntax, it would parse as map (\a b -> (c d)) rather than map (\a b -> c) d)
map \a b -> c isn't even valid syntax, the parser requires parentheses. You can use it with $ though
$\endgroup$
map \a b -> c d is valid syntax (and parses as map (\a b -> c d) with GHC, if you turn on the BlockArguments language extension.
$\endgroup$
(parameters) => body
Very concise. You can also have multiple statements if you wrap it in braces.
lambda parameters: body
A bit verbose with the keyword lambda, and also only allows one expression.
do |parameters| body end
Allows expressions or statements, but still a bit verbose.
Alternatively:
{ |parameters| body }
More concise, and also allows expressions or statements.
sub {my ($parameters) = @_; body};
Once again, allows expressions or statements, but it's even longer than Ruby.
[&](parameters) {body}
Concise and allows multiple statements.
\parameters -> expression (e.g. \x y -> x + y)
$\endgroup$
APLs (APL, J, K, BQN) have lambdas that are are unique in having a pre-defined set of argument names. E.g. APL uses prefix/infix lambdas with ⍺ for the left argument (optional) and ⍵ for the right argument. Here, we define a root function (* is exponentiation and prefix ÷ is reciprocal):
2 {⍵*÷⍺} 100
10
A lambda can be ambivalently prefix/infix by either checking if a left argument is present, or by using the convention that an attempted assignment to ⍺ is ignored if ⍺ already has a value (⋄ is the statement separator):
Root←{⍺←2 ⋄ ⍵*÷⍺}
Root 100
10
3 Root 8
2
As with all APL functions, if many arguments are needed, they can be given as an array, one element per argument, and destructured inside the function. The destructuring expression then functions as a type of header (⍳ is the range function):
{(start count step)←⍵ ⋄ start+step×⍳count} 10 5 2
10 12 14 16 18
Some APLs (K, BQN) have an explicit header syntax too, and BQN allows multiple headers for various uses, but this is the gist of it.
|parameters| -> returntype {body}
This is a rather unorthodox form, as I think only Rust uses it. However, it may be less prone to syntactic ambiguity by virtue of not using curved brackets.
| parameters | appeared in Smalltalk, I think. See this answer.
$\endgroup$
(args) -> body
This is subject to a lot of variation:
-> vs. =>){}s, or single expressions may be allowed without those
one arg
fun x -> x
multiple arg
fun f xs -> List.map f xs
==
fun f -> fun xs -> List.map f xs
In Clojure:
(fn [a b] (+ a b))
Alternative syntax (uses indexing like %1 to access params):
#(+ %1 %2)
body can be multiple expressions or statements.
Similarly, in Common Lisp:
(lambda (a b) (+ a b))
fn (parameter1, parameter2) => value
It's the same as Javascript style except it also adds a required fn keyword before. Requiring a keyword makes things a bit more explicit which is nice but it's also more verbose.
There is no benefit of consistency because normal functions are defined with function not fn.
As VLAZ pointed out there is also a long form:
$f = function ($b) use ($a) { return $a + $b; }
Which requires explicitly specifying what variables you want to capture
(parameter1, parameter2) -> expression
It's the same as javascript except using -> instead of =>
function(argument_1, argument_2) { code }
JavaScript has 2 ways of defining closures. this is handled differently in both cases.
I like this one because of the symmetry of function name() {} for named functions and function() {} for anonymous functions. A shame about how this works or I'd prefer it over ()=>{}
function you also need to import/capture values from outer scope(s), which the short fn does automatically. E.g., $a = 1; $f = function ($b) use ($a) { return $a + $b; } is the long and explicit capturing syntax, while with an arrow function it's $a = 1; $g = fn($b) => $a + $b;
$\endgroup$
The full syntax is
{ a: Foo, b: Bar -> body() }
The type annotations may be omitted, and if there is only one parameter, that can be omitted and replaced with the implicit parameter it:
{ it.bar() }
Blocks are a clang extension to C enabled with the -fblocks flag, though they're more common in -- and therefore usually associated with -- Objective-C.
The type syntax is similar to function pointers: return_type(^)(arg_types). These are typically used in typedefs, such as
typedef int(^int_function_t)(int);
The full syntax for defining one is this:
^return_type (arg_type arg_name) {
body();
}
However, the return type can usually be inferred from the body of the block. If the return type is omitted and the argument list is (void), that can be omitted, too. For example:
int (^square)(int) = ^(int x) { return x * x; };
int (^randomNumber)(void) = ^{ return 4; };
NB: the trailing semicolon after the closing brace is necessary to end the declaration statement, and is not part of the block.
Blocks are called with the same syntax as function pointers.
If you need to capture a variable by reference, you must mark it with the __block storage specifier. Otherwise, capture by value is implicit:
int x = 4;
__block int y = 4;
void (^printX)(void) = ^{ printf("%d\n", x); };
void (^printY)(void) = ^{ printf("%d\n", y); };
++x;
++y;
printX(); // prints '4'
printY(); // prints '5'
going back to the older ones:
(lambda (params) body)
[| parameters | body ]
[ body ] -- when there are no parameters
Go uses the same function declaration syntax everywhere, and lambdas are just anonymous functions.
func(){ body }
func() returnType { body }
func(parameters) { body }
func(parameters) returnType { body }
These syntaxes are equivalent, all declare a function and bind it to FuncName:
func FuncName(){...}
var FuncName = func(){...}
FuncName := func(){...}
A common pattern is to use or call functions immediately after definitions, mainly for goroutines, defer, and initializing something with a complicated calculation:
value := func(a,b,c) returnType { ... }(x,y,z)
go func() { ... }
defer func() { ... }
