[PATCH] D147131: [PoC][TabgleGen] Add new bang operator !apply

[Nicolai Hähnle via Phabricator via llvm-commits]

nhaehnle added a comment.

This is an interesting proposal, but I think it really needs a bit more thought on the overall design. If we're going to add something like this, it should be nicely orthogonal and general.

Some examples of problems in what's there right now:

- Parallel hard-coding of `add`, `sub` etc. in the parsing of IDs. Not great, since it affects parsing everywhere -- we could do that, but then what's the overall direction here with regards to `!apply` vs. the existing ops?
- Hard-coding of argument names `$aN`.

I agree with @tra that in a way this is reinventing lambdas, so perhaps we should instead just literally take lambdas? That means a syntax for defining lambdas and a syntax for applying them. Strawman riffing off apply.td, something like:

  defvar add_lambda = (lambda (lhs, rhs) !add(lhs, rhs));
  
  class A<int a, int b> {
    int add_result = !apply(add_lambda, a, b);
  }

What I'm thinking here is that the expression `(lambda (args...) expr)` is **not** a DAG but a new expression/init kind, with lambda being the keyword to detect that. The expression is evaluated with a scope where the arguments are substituted.

We could consider alternative syntaxes, two possibilities that would probably work:

  defvar add_lambda = ($lhs, $rhs) -> !add(lhs, rhs);
  defvar add_lambda = |lhs, rhs| !add(lhs, rhs);

And perhaps we can shortcut the evaluation syntax to just:

  class A<int a, int b> {
    int add_result = !(add_lambda a b);
  }

Or, perhaps:

  class A<int a, int b> {
    int add_result = !add_lambda(a, b);
  };

In other words, the syntax is `! expression ( args... )` where the expression must evaluate to a lambda. We could turn most (but not all) bang operators into builtin variables and turn a few exceptional cases into reserved keywords.

I haven't thought this through fully, just throwing some ideas out there that hopefully help suggest a cleaner and more robust design. I think this is large enough that it would also merit having a discussion on Discourse for visibility.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147131/new/

https://reviews.llvm.org/D147131