Closures and higer order functions in mojo

[ekinimo]

I couldnt figure out how to make a closure in mojo. I wonder if it is supported, or whether there are plans to support it in the future.
i just hope this will result in something more sensible than pythons result

lambdas = []
for i in range(10):
   lambdas.append(lambda x: x+i)
print(lambdas[3](0))

[ksandvik]

If this is missing, could we have labels for missing (and to be implemented) Python features so it's easy to find them in the GitHub issues database?

[DayDun]

Mojo does have closures, just not the lambda syntax yet.

from Vector import DynamicVector

var lambdas = DynamicVector[fn(Int) capturing -> Int]()
for i in range(10):
    fn f(x: Int) -> Int:
        return x + i
    lambdas.push_back(f)
print(lambdas[3](0))

But be careful about #217

[ekinimo]

So this is basicly analogous to gcc s nested functions ?

[ekinimo]

Also given code does what i expect but not what python does, if i change fn to def it fails. I think this behaviour is perfectly sensible but not compatible with python lambdas (the same code would result differently). Is this to be adressed in the future ? What should i expect ?

[DayDun]

I am not familiar with gcc nested functions. Closures in mojo work like I'd expect closures to usually work, capturing referenced variables if required.

Switching to def means f can now also raise errors, which appears to cause issues #255.

[survuvi]

@DayDun on your code how to print the full vector, so print all elements instead of only third indexed element?

from Vector import DynamicVector

var lambdas = DynamicVector[fn(Int) capturing -> Int]()
for i in range(10):
    fn f(x: Int) -> Int:
        return x + i
    lambdas.push_back(f)
print(*lambdas) #error: Expression [4]:23:12: unpacked arguments are not supported yet

[DayDun]

With a loop

[survuvi]

@ekinimo

%%python
lambdas = []
for i in range(10):
   lambdas.append(lambda x: x+i)
print(lambdas[3](0)) # Output: 9, due to the late binding closure issue

%%python
lambdas = []
for i in range(10):
    lambdas.append(lambda x, i=i: x+i)
print(lambdas[3](0))  # Output: 3

[lattner]

Ok, you need a += in there somewhere, e.g.:

 var i_1 : Int = 1
        while i_1 < 10:
            print(i_1*n)
            i_1 += 1
        return i_1

because 'while' doesn't increment the induction variable

[survuvi]

Thank you @lattner could be there is a bug bacause i_1*n not print anything

fn main(n : Int) -> Int:
    @parameter
    fn multiplication_table() -> Int:
         var i_1 : Int = 1
        while i_1 < 10:
            print(i_1*n)
            i_1 += 1
        return i_1
    return n

main(5)

[lattner]

You also need to call the multiplication_table() function :-)

[survuvi]

fn main(n : Int) -> Int:
    @parameter
    fn multiplication_table() -> Int:
        var i_1 : Int = 1
        while i_1 < 10:
            print(i_1*n)
            i_1 += 1
        return i_1
    return n

let func = main(5)

var result = func()

print(result)

print(main(5)())

_error: Expression [11]:28:22: 'Int' does not implement the 'call' method
var result = func()
^

error: Expression [11]:33:18: 'Int' does not implement the 'call' method
print(main(5)())_

[lattner]

#272 (comment)

[lattner]

Loosely held opinion, Mojo clearly needs to support:

1. Nested functions (currently wired up, but have a few issues given lifetimes are not here yet). I'd like @parameter to go away on the nested functions eventually too.
2. Existing Python lambda syntax, which is sugar for Add the initial README.md #1. We need to support type annotations here.

Lower priority, but I think we're likely to explore:

3. Possibly implement more flexible/general/ergonomic light-weight closures like Scala3 => syntax
4. User defined statement blocks, e.g.:

  parallel_loop(42):
    stuff()

User defined statements are a nice way to shift more language syntax into the library, but are just syntactic sugar and will require a little more infra to get wired up. For example, I would like "return" in that context to return from the enclosing function (not from the lambda), and things like break to work for loop-like constructs. This is quite possible to wire up, but will require a bit of design work.

[DayDun]

User defined statements would be epic. I love the idea of moving things from the compiler to libraries, but you have to of course be careful to not do it at the expense of other things.

I think it's very neat for example how Swift defines the short-circuiting && operator completely in the standard library.

[lattner]

Yep, lots of lessons there. It still bugs me how "return" works the wrong way and break doesn't work in a "closure taking control flow" function in Swift. We can do better.

[nmsmith]

Chris, one thing I would love ❤️ 😍 is to have a version of these user-defined statement blocks that supports arbitrary Unicode text within them. Mojo's parser would strip the leading indentation, tokenize the text, and pass the tokens to the block's implementation. Additionally, Mojo values could be interpolated using Python's f-string syntax {}, or something akin to it.

What I'm describing is basically a multi-line template literal, delimited by indentation, rather than " characters. I'm also proposing to pass the implementation a list of pre-tokenized lines, rather than a raw string, so that nobody has to worry about weird whitespace issues.

Library authors could use this feature to embed DSLs within Mojo, and the DSL programs can be compiled at the same time as Mojo using Mojo's metaprogramming feature, allowing them to run lightning fast. The end result could be something epic!

(A lot of details would need to be fleshed out, of course.)

[lattner]

You might have noticed that I'm a fan of powerful library-defined metaprogramming features :-). I look forward to exploring all this, but we must stay focused :-)