Expanding the function capture syntax to work for arbitrary expressions

[Olian04]

Using the function capture syntactic sugar is a great tool, I'd like for that tool to be usable in more places. For example in arithmetic, equality operations, and as the initial value of a pipe.

// Currently
[1, 2, 3, 4, 5, 6]
|> list.filter(fn(it) { it % 2 == 1 })
|> list.map(fn(it) { 
      it
      |> fn(it) { it * 2 }
      |> fn(it) { it + 1 }
    })
|> int.sum
|> fn(it) { it % 10 }
|> io.debug

// Suggested syntactic sugar
[1, 2, 3, 4, 5, 6]
|> list.filter(_ % 2 == 1)
|> list.map(
      _
      |> _ * 2
      |> _ + 1
   )
|> int.sum
|> _ % 10
|> io.debug

[lpil]

Hello! Thanks for the suggestion.

What's the rationale for this change? I would write the above like so today:

// Currently
let num =
  [1, 2, 3, 4, 5, 6]
  |> list.filter(int.is_odd)
  |> list.map(fn(it) { it * 2 + 1 })
  |> int.sum
io.debug(num % 10)

This is more concise then either example, and I think maybe clearer too.

Technical details

How would the compiler know how far up the syntax tree to ascend to get all the code that should go in the function? You seem to be using two different approaches in your example.

[Olian04]

I can see your point about the arithmetic examples and that I'm assuming a complex algorithm for resolving the capture logic (specifically the difference between _ % 10 and _ % 2 == 1). I'm willing to drop those examples from the suggested feature. However I still think that using a _ as the first argument of a pipe would be a nice feature to have.

let special_sum =
  _
  |> list.filter(int.is_odd)
  |> list.map(fn(it) { it * 2 + 1 })
  |> int.sum
  |> fn (it) { it % 10 }
  
io.debug([1, 2, 3, 4, 5, 6] |> special_sum)

[cottand]

I think the opposite reads better and is less ambiguous: keeping _ for inline arguments only, such as:

let special_sum = [1, 2, 3]
  |> list.filter(int.is_odd)
  |> list.map(_ * 2 + 1 )

previous work exists at Kotlin, Swift, etc, and are widely used in those languages. It's handy for writing small lambdas often. Given this happens already in Gleam for function captures I don't think it adds extra confusion there.

Not necessarily advocating for this, but _ could be used outside of arguments if the language enforces desambiguation:

let sum1 = { _ + 1 }
let special_sum = [1, 2, 3]
  |> list.filter(int.is_odd)
  |> list.map(_ * 2 + 1 )
  |> { _ % 10 }

[lpil]

The examples you've given there have the problem described above.

let special_sum = [1, 2, 3]
  |> list.filter(int.is_odd)
  |> list.map(_ * 2 + 1 )

This would be a type error as it would expand to this

let special_sum = [1, 2, 3]
  |> list.filter(int.is_odd)
  |> list.map(fn(x) { x * 2 } + 1 )

[cottand]

I think it depends on how the AST is structured -- if _ * 2 + 1 is a normal expression inside a function call with _ being an identifier token, the compiler can expand that top-level expression into a function after the first pass. Ie, an expression with a capture hole would be a normal expression, much like a function capture currently is a normal CallArg where one of the args is _.

But before looking into the implementation specifics (or even the specific syntax, which can be tweaked) I think it's worth first discussing if function captures for expressions is a good fit for Gleam at all? And if so, is it desirable to use them outsie of function args? etc

[lpil]

As has been said multiple times above it is impossible to know the programmer intent with the proposed syntax. It would been to be a more verbose syntax similar to Elixir's &(&1) syntax.

We don't currently have a compelling motivation to expand the function capture syntax.

[ethanthoma]

Just to add my 2-cents, I wish there was a nicer way with nested calls. Sometimes I have to wrap my functions:

pub fn init() -> Effect(msg.Msg) {
  let msg = fn(x) { msg.AuthMsg(msg.OAuthServerStarted(x)) }

  tauri.invoke("start_server", [], tauri.expect_json(zero.int, msg))
}

But I would find it prettier if I could just:

pub fn init() -> Effect(msg.Msg) {
  let msg = _ |> msg.OAuthServerStarted |> msg.AuthMsg

  tauri.invoke("start_server", [], tauri.expect_json(zero.int, msg))
}

Or if there was some func comp thing like haskell that im not aware of

[lpil]

Please see the above discussion for why this syntax is not possible.

[giacomocavalieri]

And you can always use a pipe in the anonymous function if you find it more readable:

  pub fn init() -> Effect(msg.Msg) {
+    let msg = fn(x) { x |> msg.OAuthServerStarted |> msg.AuthMsg }

    tauri.invoke("start_server", [], tauri.expect_json(zero.int, msg))
  }

[ethanthoma]

Sorry if this is asking too much, but I'm somewhat not sure I understand why it would be an issue for the syntax tree.

Is it for when there are multiple underscores when recursing the expression? Or is it an issue that the compiler wouldnt know where to wrap the expression with a anonymous function once it found the underscore?

[GearsDatapacks]

In the example you gave:

_ |> msg.OAuthServerStarted |> msg.AuthMsg

There are two possible ways to interpret this:

fn(x) { x |> msg.OAuthServerStarted } |> msg.AuthMsg

or

fn(x) { x |> msg.OAuthServerStarted |> msg.AuthMsg }

There is no way for the compiler to determine which one is correct. Only you know your intention for it

[ethanthoma]

Oh makes sense, Ty!

[andho]

All these example feels like a short hand function definition.
Like in js function(a) { a * a; } can be a => a * a
Or elixir fn a -> a * a end can be &(&1 * &1)
Even rust allows to omit the curly brace |a| a * a