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

• 5544

• 6538

• 7890

• 8350

• 9871

• 11985

• 11987

• 14173, #14483, #14484

• 18413

• 16128

• 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.