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

[Wang Pengcheng via Phabricator via llvm-commits]

pcwang-thead marked 2 inline comments as done.
pcwang-thead added a comment.

In D147131#4232652 <https://reviews.llvm.org/D147131#4232652>, @nhaehnle wrote:

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

Thanks! It's really helpful and inspiring!
I will redesign this and make it much more complete before discussing on Discourse.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147131