First class functions / lambdas

[mppf]

This issue tracks problems with first class functions.

Design needed

The language design for first-class functions is not complete. It's unclear if capturing variables is legal, and if so, how they are captured. See also #11506.

Workaround

First-class functions are currently translated by the compiler into classes with this methods. An alternative (that has better support) is to declare a "function object" like so:

proc main(){
  var x = 10;

  record Lambda {
    proc this(z:int) {
      return z*x;
    }
  }
  var foo = new Lambda();

  writeln(foo(3));

}

Relevant issues

• Internal compiler error using lambdas #5544
• Missing error message when returning an inner function that uses an outer-local var #6538
• First-class functions leak #7890
• Anonymous Function with scope variable Bug #8350
• Syntactic sugar for first-class functions #9871
• Passing a function with an array argument results in internal error #11985
• const checking problem with first class functions #11987
• Cannot use writeln to print result of lambda #14173, 'param' first-class functions #14483, Function call misinterpreted as a FCF #14484
• Internal error when assigning lambdas #18413
• Qualified access of first class functions #16128
• Should Chapel support FCFs implemented as function pointers? If so, how? #18442

Design Precedents

It might be interesting to investigate function arguments in Swift and C++11 lambdas as design points.

[ben-albrecht]

Using this issue as a place to track shortcomings of today's FCFs (without opening new issues), as kind of a PSA for anyone searching for FCF issues:

• Today's FCF implementation relies on virtual dispatch, which makes them unsuitable for any performance-critical codes.

[mppf]

It might be better for a series of begin-on statements as might come up in chained futures for the first class functions to be allocated on the heap. An interesting case to think about is getting the length of a distributed linked list with chained futures. We don't want the originating stacks to have to remain around for some reason.

[mppf]

The current implementation doesn't have a way to reason about the type of a throwing first-class-function.

[LouisJenkinsCS]

Should there be individual issues to discuss specific parts of First Class Functions design?

[mppf]

Yes, and there are, e.g. #11506 and #9871.