-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
Dispatch based on compile-time function evaluation #8154
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
Comments
Could the same problem be solved by a dynamic Union type? eg function has_time_axis(A::NamedAxesArray)
any(n -> n == :time, axesnames(A))
end
const Has_time_axis = DynamicUnion(has_time_axis) An extendible Union type, might also be a building block for interfaces, where the |
I find type Value{B} end
gpi(img::AbstractArray, i::Real, j::Real) = gpi(img, i, j, Value{has_time_axis(img)})
gpi(img, i, j, ::Type{Value{true}}) = timeslice(img, i, j)
gpi(img, i, j, ::Type{Value{false}}) = img[i,j] Remember also the constructor trick: type gpi{B}
if B
gpi(img, i, j) = timeslice(img, i, j)
else
gpi(img, i, j) = img[i, j]
end
end
gpi(img::AbstractArray, i::Real, j::Real) = gpi{has_time_axis(img)}(img, i, j) |
BTW, it seems that staged functions can be emulated in this case, unfortunately this is not inlined apparently: type has_time_axis{A}
ret = any(n -> n == :time, axesnames(A))
has_time_axis() = ret
end
has_time_axis{A<:NamedAxesArray}(::A) = has_time_axis{A}() |
@rfourquet, one way to make this less confusing is to view the current |
You are right, though that if I modified the stagedfunction to return
then I could dispatch on it. Not as pretty a syntax, however 😄. |
I don't think a special feature is needed for this. Being able to dispatch on |
Yep, that's reasonable. |
Over in #2345 (comment), I point out that this basically gives us multiple inheritance (it's traits-based rather than type-based). |
Once staged functions land, my next wish-list item 😄 will likely be the ability to dispatch based on a boolean-valued function:
This kind of dispatch is difficult to express with conventional mechanisms, because
img
might have any of the following types:etc. Of course one can use non-dispatch based mechanisms, but those incur runtime overhead and might not be type-stable.
Ideally, the function after
::
could accept more than just the argument itself.has_n_spatial_dimensions(img, 2)
, etc.Any thoughts about whether this is worth the effort? I should emphasize that this is highly speculative, and I am concerned about suggesting big changes to Julia for a use case that may yet crumble 😉. So we should make sure there are other applications for this idea, too.
The text was updated successfully, but these errors were encountered: