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

Add support for f ∘ g #317

Merged
merged 3 commits into from
Jan 4, 2022
Merged

Conversation

pdeffebach
Copy link
Collaborator

This PR does not transform f(g(:x)) to (f ∘ g)(:x).

Rather, it ensures that the expression

:y = (f ∘ g)(:a, :b)

gets turned into

[:a, :b] => (f ∘ g ) => :y

which is a good first step for transforming f(g(x)).

I'm leaving this undocumented for now, since it's a behind-the-scenes transformation.

@pdeffebach
Copy link
Collaborator Author

pdeffebach commented Jan 2, 2022

@bkamins can I get an review? I have code ready based on this which will do the more substantive change of transforming f(g(:x, :y)) into (f ∘ g)(:x, :y).

@@ -187,4 +189,38 @@ using DataFramesMeta
end
end
end

@testset "composed compilation" begin
@eval begin
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here - I do not understand the benefit of @eval?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned above, @eval is necessary because we need to evaluate in global scope to prevent caching the anonymous function in the method table.


for _ in 1:2
@eval begin
@test @select(df, :y = (f ∘ g)(:a, :b)).y == [3]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think testing timing is enough? Maybe also generated code should be tested?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't check generated code anywhere else. I think this should be enough.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nevermind it's easy to add. Added. Will merge after tests.

src/parsing.jl Show resolved Hide resolved
Copy link
Member

@bkamins bkamins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apart from the comments left I think it looks good. The code assumes that is not redefined by the user, but I think it is a valid assumption (though maybe it should be noted somewhere).

@pdeffebach
Copy link
Collaborator Author

No that's a good catch. Overall I'm not very good with macro hygiene in this package and should fix it.

@bkamins
Copy link
Member

bkamins commented Jan 3, 2022

I am not sure who is good at macro hygene 😄 (e.g. I do not write macros often and in consequence it is really hard for me to do it properly when I do).

@pdeffebach
Copy link
Collaborator Author

Macro hygiene doesn't matter here, actually. Since the expression f ∘ g is just "moved" not changed in any way. And it is assumed to be callable both before and after the transformation.

@pdeffebach pdeffebach merged commit 3ecdb78 into JuliaData:master Jan 4, 2022
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

Successfully merging this pull request may close these issues.

2 participants