Skip to content
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

Consider subtyping Function #37

Closed
andyferris opened this issue Oct 25, 2021 · 8 comments
Closed

Consider subtyping Function #37

andyferris opened this issue Oct 25, 2021 · 8 comments

Comments

@andyferris
Copy link

andyferris commented Oct 25, 2021

Hi,

One thing that can help with compatibility elsewhere is to hint your lenses and so-on are functions, by directly subtyping Function.

For example the code at https://github.com/JuliaObjects/Accessors.jl/blob/master/src/optics.jl#L345 could become:

struct PropertyLens{fieldname} <: Function
end 

This came up in SplitApplyCombine, which (unfortunately) is currently using Base.Callable in a few cases (although I wish the API were factored so it were obvious which terms must be functions rather than collections), here.

CC @aplavin

@jw3126
Copy link
Member

jw3126 commented Oct 26, 2021

While I am not a friend of dispatching on Base.Callable I can see that it might be pragmatic to do so. I am open to such a PR. One hassle is that we don t want the default printing of functions. Is there more baggage we inherit from subtyping function?

@andyferris
Copy link
Author

One hassle is that we don t want the default printing of functions. Is there more baggage we inherit from subtyping function?

Hmm, it's never really given me baggage before - but yeah good point about the printing.

@tkf
Copy link
Member

tkf commented Nov 11, 2021

FWIW I think the main downside of subtyping Function is that the compiler de-optimizes a higher-order function that does not call the argument. (Though I really wish it stops doing this...)

IMHO an API that dispatches on Callable or Function is an anti-pattern and, ideally, should be refactored, as in JuliaLang/julia#34296

@andyferris
Copy link
Author

is that the compiler de-optimizes a higher-order function that does not call the argument

Really? That's weird.

IMHO an API that dispatches on Callable or Function is an anti-pattern and, ideally, should be refactored, as in JuliaLang/julia#34296

You're probably right on that one.

@tkf
Copy link
Member

tkf commented Nov 11, 2021

I was referring to this issue JuliaLang/julia#33978

@andyferris
Copy link
Author

I see - I can think of it working like ::Type{T} then. At least now I know - thanks!

When I opened this issue I didn't see any possible downsides but it's more complex than I imagined, so I'll close this one.

@aplavin
Copy link
Member

aplavin commented Nov 11, 2021

FWIW I think the main downside of subtyping Function is that the compiler de-optimizes a higher-order function that does not call the argument.

Does this behavior differ depending on whether the passed callable is a Function or not?

@jw3126
Copy link
Member

jw3126 commented Nov 11, 2021

Does this behavior differ depending on whether the passed callable is a Function or not?

Types also get deoptimized unless you do f(::Type{T},...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants