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
I like that we support expression literals (as a side effect of comparing values):
But while we do accept
_in the struct construction syntax, we don't support them in the expression literal syntax: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:
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
@matchmacro 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: