Add lambdas with statements / local functions in imp syntax

[developedby]

Currently, in imp syntax there is no way of writing lambdas that have statements in them.
We can raise them to proper top-level functions, but then any captured variables must be passed through additional arguments, which increases the overhead.
But the main problem is that it's very inconvenient to do so. Instead we'd like a way to write lambdas with statements like we can do in Fun syntax.

I'll propose two possible syntaxes here.

def foo:
  lambda x:
    ...
    return y
  return z

Here lambda x defines a block for a local anonymous function bound to variable x.
I thought of this as just a simple lambda/closure, that can freely capture variables and doesn't get lifted into a separate definition.

Another option is

def foo:
  def foo/local(a, b):
    ...
    return c
  return foo/local(x, y)

This defines a function that is raised as a top-level. Captured variables are passed as arguments implicitly through a use term, like this

def foo:
  use foo/local = foo__local_foo/local(captured1, captured2)
  ...
  return foo/local(x, y)

This allow local functions to be recursive, but adds an overhead compared to just a simple lambda. And if the lambda is affine, it will get floated anyway.

I don't know which is better, need to think more about it.
I think we don't need both syntaxes, but that could also be an option.

Also, note that either syntax could have either of the described behaviours, I just think that they sort of imply intuitively the behaviours i described.

[developedby]

Another advantage of the second syntax is that it would be similar to python (except for the lack of nonlocal and global)

[arnfaldur]

I apologize for the off-topic comment.

When I first saw Bend, during the recent hype cycle, I was very excited.
I saw that it wasn't quite ready for anything I would want to use it for at the time.
But there was huge obvious potential.

Looking at the issues section, I'm in awe of your diligence. There is obviously great work happening here and I just want to leave you with these words of encouragement. I'm very impressed, and you should be proud of all this progress.

[developedby]

I apologize for the off-topic comment.

When I first saw Bend, during the recent hype cycle, I was very excited. I saw that it wasn't quite ready for anything I would want to use it for at the time. But there was huge obvious potential.

Looking at the issues section, I'm in awe of your diligence. There is obviously great work happening here and I just want to leave you with these words of encouragement. I'm very impressed, and you should be proud of all this progress.

Thank you very much for your words. If there's anything specific you'd like to see in Bend, please create an issue and we'll be happy to at least look into it.

[arnfaldur]

The main thing I noticed was lacking when I first looked was that there seemed to only be one datatype which was an integer of a certain size. That indicated to me a lack of maturity and because of it, I expected to encounter other things missing, if the project was still at such an early stage.

Judging by the issues, floats have been added, which is good. I don't have a specific project in mind at the moment that Bend would be a good fit for, so I'm afraid I don't have much useful input regarding important next features. The current issue list seems good though. atan2 is for example a useful addition, as well as the lambda idea in this issue, and a file reading issue I saw. So I believe you're on a good track already.

I'll be watching the project, and will have it in mind for any future projects. If I ever think of something useful, I'll suggest it, or contribute. Thanks again and good luck!

[developedby]

Having some time to things about it, I think we should add both lambdas with statements and local functions.

I'm thinking that we'll use high order functions a lot for error handling (things like Result/then, Result/ok_or, etc) and being able to declare most of the functions we pass to these error handlers inline will help a lot with readability.

In python this is not much of a concern since errors are exception that you catch and lambdas are very rare.

[developedby]

While writing some more Bend code, I noticed that it would also be useful to have local functions in fun syntax.
Mostly to avoid polluting the namespace, especially in the context the prelude/standard library.