
Description
I like that we support expression literals (as a side effect of comparing values):
julia> @match :(5+5) begin
:(5+5) => true
_ => false
end
true
But while we do accept _
in the struct construction syntax, we don't support them in the expression literal syntax:
julia> @match :(5+5) begin
Expr(:call, [:+, _, _])=> true
_ => false
end
true
julia> @match :(5+5) begin
:($_ + $_) => true
_ => false
end
ERROR: syntax: all-underscore identifier used as rvalue around /Users/nathan.daly/.julia/packages/Rematch/MQlXA/src/Rematch.jl:72
I think the error happens because after #5, we're trying to actually use the value in the _
variable in scope. But I think this should respect our other uses of _
as a rhs variable to mean a wildcard.
Same problem with these:
julia> @match :(5+5) begin
:(a_ + b_) => true
_ => false
end
false
julia> @match :(5+5) begin
:($a_ + $b_) => true
_ => false
end
ERROR: UndefVarError: a_ not defined
Stacktrace:
[1] top-level scope at /Users/nathan.daly/.julia/packages/Rematch/MQlXA/src/Rematch.jl:72
It's a bit weird because the $
interpolation means something inside :()
and also now means something inside @match
. And the names of variables mean something different inside the expression literal than outside it. So i'm not really sure what the right behavior is here...
Fwiw, MacroTool's @match
macro gets around this problem because they are always matching expressions by default, not values, so they just always coopt names w/ _
inside expression literals.
There's also this option which currently fails. It would feel wrong to me to make this match because of the potential for an actual _
inside the expression, but I guess this would be most similar to what MacroTools does:
julia> @match :(5+5) begin
:(_ + _) => true
_ => false
end
false