You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Kinda a weird case, but I was thinking about how it'd be nice to be able to use the form (@foo x y) instead of @foo(x, y) to avoid having to write commas, but currently the parser demands that there's no whitespace in the middle of a macro arguments.
Maybe a more realistic example of where one might want to do this would be
Is this something we could reasonably allow? I guess the worry is that it could alternatively be interpreted as (@foo(x); y) instead of (@foo(x, y)), but I think the parsing as (@foo(x, y)) is more consistent with how we handle infix operators, e.g.
julia> (1+2)
3
The text was updated successfully, but these errors were encountered:
As we discussed at JuliaCon, I feel we can probably make this work (despite the issues you ran into). It "probably just" involves some subtle handling of ParseState flags.
Complicated macro names like (A.B.@x y z) also need to work. And the whitespace rules which you need for this need to be disabled when entering a further context. Like
Copying from JuliaLang/julia#52842:
Minimal example:
Kinda a weird case, but I was thinking about how it'd be nice to be able to use the form
(@foo x y)
instead of@foo(x, y)
to avoid having to write commas, but currently the parser demands that there's no whitespace in the middle of a macro arguments.Maybe a more realistic example of where one might want to do this would be
Is this something we could reasonably allow? I guess the worry is that it could alternatively be interpreted as
(@foo(x); y)
instead of(@foo(x, y))
, but I think the parsing as(@foo(x, y))
is more consistent with how we handle infix operators, e.g.The text was updated successfully, but these errors were encountered: