One more step to enable end-to-end p/erformant experience of FEC without relying/fallback to BCL. I know that interpreters can be fast. We have a small subset implemented successfully in DryIoc https://github.com/dadhi/dryioc. In addition to overall performance design we may expose api to hook the direct calls to the user provided code (methods).
I remember talk from Unison creator which on the performance of interpreters and breaking misconception of them being slow.
Adjacent but not exactly: fec already outputs valid C# code - may research the
SourceGenerators/interceptors to generate sources for expressions and execute the with native speed, see DryIoc compile time container leveraging t4 and fec c# output to do exactly that. How cool it would be if we enable such thing in fec with nice ux/dx?
One more step to enable end-to-end p/erformant experience of FEC without relying/fallback to BCL. I know that interpreters can be fast. We have a small subset implemented successfully in DryIoc https://github.com/dadhi/dryioc. In addition to overall performance design we may expose api to hook the direct calls to the user provided code (methods).
I remember talk from Unison creator which on the performance of interpreters and breaking misconception of them being slow.
Adjacent but not exactly: fec already outputs valid C# code - may research the
SourceGenerators/interceptors to generate sources for expressions and execute the with native speed, see DryIoc compile time container leveraging t4 and fec c# output to do exactly that. How cool it would be if we enable such thing in fec with nice ux/dx?