-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Typeinference depends on execution order but should not #45388
Comments
It's probably due to julia> eltype((1,2.,""))
Any since that's what usually ends up in I had the same problem in PropCheck.jl with recursive Either way, inference is allowed to fail, so unless someone figures out how to make inference in general smarter for these cases or figures out how to fix |
Hi @Seelengrab that is definitly a good hint to keep in mind. It is however not related to what is run here as far as I understood the issue. TypeClasses.flatmap is more like Base.map with many different implementations and the once which use Iterators.flatten are not those which are active here. The relevant implementation of TypeClasses.flatmap is the one for ExtensibleEffects.Eff using ExtensibleEffects: Eff, Continuation
TypeClasses.flatmap(f, eff::Eff) = Eff(eff.effectful, Continuation(eff.cont.functions..., f)) Nothing with element-types as far as I can see. But with plain constructors and varargs. |
@Seelengrab do you know someone who can help on this? |
As a temporary fix, you can define this with julia >= 1.7 which(ExtensibleEffects.Eff, Tuple{Any,ExtensibleEffects.Continuation}).recursion_relation = (@nospecialize(_...)) -> true to turn off the recursion check and make sure the inference success. |
Seems like it's a same issue as #35800 (is there any place where your package (explicitly or implicitly) uses |
in the example stated above I am using |
Also What I learned by reading through the issue you linked: |
I made another attempt at getting into the details of this problem and went a completely different route. Because it is unclear whether the underlying issue is the same or a different one, I created a new issue for it: #47694 |
Hi there,
this issue was already discussed on discourse. While we could gather some clarification, it couldn't be solved. Hence I raise it as an issue here.
I am the author of ExtensibleEffects.jl and TypeClasses.jl and experience crucial performance difficulties due to bad type inference. As I got multiple requests from the community whether ExtensibleEffects.jl could be made fast, I want to tackle these problems.
ExtensibleEffects.jl is an advanced functional package, hence please bear with me if the following example looks not understandable why you ever would like to do something like this. It is a minified version of the actual ExtensibleEffects code, and I am very sorry that I was not able to simplify it anyway further so far. At least it is reproducible and fits into an issue.
My Motivation
if you want to understand the motivation for the example, this might help
```julia using ExtensibleEffects using TypeClasses using Testvector_of_eff_of_vector = map(x -> noeffect([x]), [1, 20])
e1 = vector_of_eff_of_vector[1]
e2 = vector_of_eff_of_vector[2]
some functional monadic helpers to work WITHIN the effects
mygoal(e1, e2) = @syntax_flatmap begin
v1 = e1
v2 = e2
@pure [v1; v2]
end
The case boils down to something like the following
If this could be stabilized, much is gained for ExtensibleEffects.jl
Same code, two execution orders, one fails, the other infers
Here the one which works
And here the one which fails
It seems that a top-level call to
TypeClasses.flatmap
at the right place informs the compiler about things it usually does not have available (but should have available).This drives me crazy 😄 I feel like a little child: 10 years programming experience are not enough to solve this on my own, I am depending on you deep core Julia developers and hope someone recognizes what is going on here.
(tested on Julia 1.7.1 and Julia 1.8.0-beta3.4)
```julia julia> versioninfo() Julia Version 1.7.1 Commit ac5cc99 (2021-12-22 19:35 UTC) Platform Info: OS: Linux (x86_64-pc-linux-gnu) CPU: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz WORD_SIZE: 64 LIBM: libopenlibm LLVM: libLLVM-12.0.1 (ORCJIT, icelake-client) ```The text was updated successfully, but these errors were encountered: