You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
checkout some https://github.com/dadhi/FastExpressionCompiler and DryIoC #65
Thank you for the link. The magic happens in the ToCSharpPrinter class and in the ToExpressionPrinter class. It may be interesting to extract these into a separate project and see how they perform in unit tests against this library.
Wow, wow :) this lib does much more than mine.. great job. For now, mine are more of the diagnostics helpers to the compiler (though I have plans to use C# output for the code gen later).
@zspitz Btw, do you handle the expressions with the block on the right side of the assignment, or inside the ternarary - I mean the cases where in C# you must have an expression but the Expression trees allow the blocks?
Btw, do you handle the expressions with the block on the right side of the assignment, or inside the ternarary - I mean the cases where in C# you must have an expression but the Expression trees allow the blocks?
I try. I was under the (apparently mistaken) impression that C# supports the , operator, which (in other C-style languages) has the same semantics as a BlockExpression -- multiple statements, and the last expression becomes the value of the entire expression. I will have to rethink this.
But my goal is a little different -- I'm not aiming for code that is completely syntactically correct, but rather a string that uses C# constructs as much as possible to represent an expression tree. So, for example, VB.NET doesn't have a standalone block structure; the grouped statements are always in the context of some other syntax -- For Each, or a method, or an If...Then. So if I have a BlockExpression without any other context, I represent it as a Block ... End Block syntax, which (I think) gets the point across, even if it isn't syntactically valid.
There will always be expressions that can't be represented in a given language; C# is the best in this regard, but aside from BlockExpressions there's also unsupported dynamic operations -- DeleteIndexBinder and DeleteMemberBinder -- which other languages support.
And so, it might be better to render BlockExpression in an expression context, as standard curly-braced blocks.
Interesting, thanks for the doc link. My goal is to provide a compilable C# as much as possible, as I plan the code-gen and also extract the result output to the tests.
Activity
zspitz commentedon Oct 31, 2020
Thank you for the link. The magic happens in the ToCSharpPrinter class and in the ToExpressionPrinter class. It may be interesting to extract these into a separate project and see how they perform in unit tests against this library.
dzmitry-lahoda commentedon Nov 1, 2020
@dadhi
dadhi commentedon Nov 1, 2020
Wow, wow :) this lib does much more than mine.. great job. For now, mine are more of the diagnostics helpers to the compiler (though I have plans to use C# output for the code gen later).
@zspitz Btw, do you handle the expressions with the block on the right side of the assignment, or inside the ternarary - I mean the cases where in C# you must have an expression but the Expression trees allow the blocks?
zspitz commentedon Nov 1, 2020
@dadhi Thanks for the kind words.
I try. I was under the (apparently mistaken) impression that C# supports the
,operator, which (in other C-style languages) has the same semantics as a BlockExpression -- multiple statements, and the last expression becomes the value of the entire expression. I will have to rethink this.But my goal is a little different -- I'm not aiming for code that is completely syntactically correct, but rather a string that uses C# constructs as much as possible to represent an expression tree. So, for example, VB.NET doesn't have a standalone block structure; the grouped statements are always in the context of some other syntax --
For Each, or a method, or anIf...Then. So if I have a BlockExpression without any other context, I represent it as aBlock ... End Blocksyntax, which (I think) gets the point across, even if it isn't syntactically valid.There will always be expressions that can't be represented in a given language; C# is the best in this regard, but aside from BlockExpressions there's also unsupported dynamic operations -- DeleteIndexBinder and DeleteMemberBinder -- which other languages support.
And so, it might be better to render BlockExpression in an expression context, as standard curly-braced blocks.
dadhi commentedon Nov 1, 2020
Interesting, thanks for the doc link. My goal is to provide a compilable C# as much as possible, as I plan the code-gen and also extract the result output to the tests.