Open schlichtanders opened 1 year ago
@N5N3 do you know why
which(myeff_flatmap, Tuple{Any, Any}).recursion_relation = (@nospecialize(_...)) -> true
does not work here?
I didn't test it locally. Looks like myeff_flatmap
would cause call chain like Eff
-> myeff_flatmap
-> Eff
-> myeff_flatmap
-> ...
In this case, you have to loose the recursion check of Eff
and myeff_flatmap
at the same time to make sure the inference success.
You can use Cthulhu.jl
to check if the inference is blocked in Eff
. If so, then I think this is a duplicate of #45759. (As inference_works
is a good example that the compiler would do eager inference on direct recursion. Eff
-> Eff
-> Eff
-> ...)
Hi there,
I am suprised by some poor inference which happens by introducing a new function layer. I think somehow this triggers a special recursive case which is poorly resolved.
I am the author of ExtensibleEffects.jl and am trying to track down performance problems. I have now been able to produce a minimal example (as minimal as I could get it so far), which at least is self-contained and does not need ExtensibleEffects.
Example
Here is the basics which we need to run the tests. It is a minimal implementation for Algebraic Effects.
If you directly use the
Eff
constructor, everything works nicelybut if you wrap the typical Eff construction into its own separate function, the inference fails.
I was not able to find anything useful to fix this. I heard about a trick
which(myeff_flatmap, Tuple{Any, Any}).recursion_relation = (@nospecialize(_...)) -> true
, but I couldn't make it work, if it could work at all.My best bet is that this has something to do with the point that
myeff_flatmap
is called recursively within the call.Workaround
My current workaround is to write the function as a generated function instead, so that the code is inlined, which works as expected and does not require too much boilerplate.
Julia version