-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Allow macrocall as function sig #55040
base: master
Are you sure you want to change the base?
Conversation
I think this makes sense. A macro call is a very similar form to a call so it fits smoothly, and you might as well be able to generate a function signature with a macro. |
src/julia-parser.scm
Outdated
decl-sig))) | ||
(let ((ex (parse-unary-prefix s))) | ||
(if (and (pair? ex) (eq? (car ex) 'macrocall)) | ||
ex |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the only tricky bit --- do we allow function @mac(x, y)::T
(or with where
) or does the macro generate the entire signature? Probably the latter (as you have it) but it made me stop and think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can allow both
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already have that @mac(x, y)::T
is allowed in call position and the ::T
is not passed to the macro (unfortunately)
I guess we can allow you to return more syntax than the macro receives, but it seems a bit odd since it means you can end up generating redundant and/or conflicting type assertions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think a redundant expansion, you can always do the same directly without going through the parser. Needs to be some kind of lowering error or be given semantics. But that's independent of whether it's a legal parse or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just mean that the macro can't handle the case that it wants to insert a type assertion when one is already present - the obvious way to do that would have been to pass that syntax to the macro but I don't think we can do that
Unless I'm missing something?
Seems like people like the change, so I've addressed @JeffBezanson 's review comment and put up the same change in JuliaSyntax.jl |
Wait what? Surely this is breaking - this syntax already means something different in the existing parser:
|
Oh, I see - |
Doesn't work for me in JuliaParser (without my PR):
I guess it accidentally worked for no method body? |
That's ... surprising and weird! But yes, correct. |
So here's a bit of an annoyance. What does
parse to? |
@KristofferC requested that `function @main(args) end` should work. This is currently a parse error. This PR makes it work as expected by allowing macrocall as a valid signature in function (needs to exapand to a call expr). Note that this is only the flisp changes. If this PR is accepted, an equivalent change would need to be made in JuliaSyntax.
Actually, we already have that exact logic for the |
Oh yeaah. This was a whole big pain to get right in JuliaSyntax! Glad you could reuse the existing implementation! (Conversely the flisp parser doesn't produce a sensible parse tree in various cases related to anon functions with |
@KristofferC requested that
function @main(args) end
should work. This is currently a parse error. This PR makes it work as expected by allowing macrocall as a valid signature in function (needs to exapand to a call expr). Note that this is only the flisp changes. If this PR is accepted, an equivalent change would need to be made in JuliaSyntax.