bartdesmet
commented
2 years ago The approach taken by this project is "by design" and part of attempts to stir the discussion around taking forward expression tree support in C#:
- https://github.com/dotnet/csharplang/blob/3c8559f186d4c5df5d1299b0eaa4e139ae130ab6/meetings/2015/LDM-2015-04-14.md
- https://github.com/dotnet/csharplang/blob/3c8559f186d4c5df5d1299b0eaa4e139ae130ab6/meetings/2015/LDM-2015-04-22-Design-Review.md
- https://github.com/dotnet/csharplang/blob/3c8559f186d4c5df5d1299b0eaa4e139ae130ab6/meetings/2018/LDM-2018-06-06.md
- https://github.com/dotnet/csharplang/blob/8cb45218b0414d688c8f72c56524529554c7d7f2/meetings/2021/LDM-2021-04-07.md#expression-trees
- https://github.com/dotnet/csharplang/blob/7e2455955c480b067002569618cb902b47347bd1/meetings/2021/LDM-2021-08-30.md#expression-trees
In one interpolates the LDM meetings and the commit history over here (and related Roslyn branches), a storyline can be spotted, where I started from adding the needed nodes to support the Reaqtor project.
For Reaqtor, we used a front-end web portal running a fork of Roslyn where users could define the equivalent to "stored procedures" but for standing event processing, using the same .NET client libraries for Reaqtor but with the sole difference of getting more expressiveness in various clauses of queries (e.g. async predicates in Where, selectors with ?. in Select, actions using statement trees in Do, etc.). The code that would instantiate these parameterized queries (often millions of times) just ran using the regular C# compiler etc. (much like you'd define a stored procedure or user defined function using SQL tooling and then use regular LINQ outside).
The approach taken was simply to have reducible extension nodes of existing expression tree APIs, so they can be Reduced to more primitive forms, which readily support expression tree serialization at https://github.com/reaqtive/reaqtor/tree/main/Nuqleon/Core/LINQ/Nuqleon.Linq.Expressions.Bonsai.Serialization. They're also fully bound with all kinds of Type and MemberInfo information, so readily executable (through compilation or interpretation).
Later, I explored the notion of "expression-tree-like types" after the 2018 LDM meeting, which is in a separate Roslyn fork. My plan is to eventually unify these prototypes, such that the binding targets of the Roslyn compiler to expression factories can be implemented by any "builder" type.
Most recently, over the holiday season of 2021, I turned the crank one more time in response to discussions we had in August 2021, with the prototype now being up to C# 10.0 (and some seeds of C# 11.0 features as well). Further LDM discussions are pending, see the last link above where Entity Framework folks are expressing an interest to move this forward as well (after, for the longest time, being held back by compat concerns). Also see https://github.com/dotnet/csharplang/discussions/4727.
First of all I want to say thank you for your contribution.
I really like your idea to extend the expression tree generation with all the stuff you implemented. But what I do not like is that it needs your custom roslyn-fork to do that. I would very much prefer I it would be implemented via CSharpSyntaxRewriter and could be used with regular roslyn / csc.