-
-
Notifications
You must be signed in to change notification settings - Fork 47
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
Rule Macro Quotes Function Names #87
Comments
This should return true even with this change. This is a bug of the capture macro i guess. The pattern matcher should support both function names and objects. Code in SymbolicUtils.jl didn't change and aymbolicutils still uses function objects in terms. Will look into it ASAP |
This comment has been minimized.
This comment has been minimized.
What do you mean??? How is this even possible? |
Let's please add all those cases into the tests. |
Yes. Test cases should be extended. Im currently not at my laptop but will look into fixes asap. Metatheory.jl/test/test_reductions.jl Line 154 in 3b6b115
|
I extended this im order to check for both symbols and function objects as operations. |
I would like to clarify that I have simply switched to an old version of SymbolicUtils which I'll probably work with for a while, so please do not feel rushed on my behalf. I don't understand why we need to convert functions to symbols and then re-engineer lexical scoping rules. In my case,
|
Do instead.
See also Lines 141 to 159 in 3b6b115
maybe it should be changed to respect this By the way,
These tests all pass with this definition |
Ah yes, that was a typo. When the typo is corrected, the expression still returns false. Here's the improved steps to reproduce issues
|
My apologies for the confusion surrounding that typo. I made that mistake when copying my test code from the REPL to github. |
I agree that that mechanism is somehow intricate. There's a big TODO REVIEWME comment at the top but it never was reviewed. Line 96 in 3b6b115
It is not re-engineer lexical scoping rules. It's just saying that other than by its object, a symbolic term operation can and should be identified inside a module by its name most of the times. As a counterexample, I don't think that people will ever write pattern match rules with lambdas as pattern operations in f-application terms, such as @rule (x -> x^2)(a) --> 1 , because then
julia> f = (x -> x^2)
#1 (generic function with 1 method)
julia> g = (x -> x^2)
#3 (generic function with 1 method)
julia> f == g
false But if you give operations a name julia> foo = sin
sin (generic function with 13 methods)
julia> foo == sin
true Instead of storing the module and the symbol inside of Metatheory's goal is to get to do both things right. To do both match-on-sym-and-substitute and match-on-fun-and-eval.
Yes. This makes sense now. By now. Solution 1: allow for using Solution 2: Extend But then what should be I would go for using |
This does not work. The capture macro is broken. #86
These tests work on master. @testset "Matchable struct" begin
struct qux
args
qux(args...) = new(args)
end
TermInterface.operation(::qux) = qux
TermInterface.istree(::Type{qux}) = true
TermInterface.arguments(x::qux) = [x.args...]
@capture qux(1, 2) qux(1, 2)
@test (@rule qux(1, 2)=>"hello")(qux(1, 2)) == "hello"
@test (@rule qux(1, 2)=>"hello")(1) === nothing
@test (@rule 1=>"hello")(1) == "hello"
@test (@rule 1=>"hello")(qux(1, 2)) === nothing
end |
cc @shashi |
All that is well and good but I'm not convinced that the syntax to write rules for them should be the exact same!! In my opinion they should definitely be different, in at least accepting a flag or something. They do different things. |
Anyway can we release the fix soon? |
I'd like to propose a solution 3. Define a type for name-only functions, e.g.
or perhaps something like
or if you didn't want the name in the type domain
And of course a corresponding sugary macro
With one of these abstract function types/objects, we wouldn't ever need to parse function names as symbols, since the |
@peterahrens fixed |
Looking back on this, I think that all the bugs here have been fixed, and the last example I posted reflects a reasonable change to the interface of the rule macro. I understand that there are many different use cases that need to be supported by Metatheory, and the new interface reflects this broader scope. Thanks to everyone involved for all of your quick responses to this issue! |
I am reopening this issue to ask: If I file a PR to change the macro not to quote AST head nodes (as they may be enums, strings, custom structs, out of scope, etc.), would there be room for this change in any future release of Metatheory? |
Yes absolutely
|
This should finally be solved in #169 julia> @macroexpand(@rule(foo(~bar) => 1)) |> Base.remove_linenums!
quote
Metatheory.Syntax.DynamicRule((PatTerm)(:call, if isdefined(Main, :foo)
foo
else
:foo
end, [~bar]), ((_lhs_expr, _egraph, bar)->begin
1
end), $(QuoteNode(1)))
end Now when constructing @willow-ahrens please see JuliaSymbolics/TermInterface.jl#21 for "quoting AST head nodes", as it should be done first. |
That's a clever fix! Awesome! I wonder if this would mean we can also remove this: Lines 92 to 97 in 7828344
By the way, I'm not sure where I'm supposed to look in JuliaSymbolics/TermInterface.jl#21 for "quoting AST head nodes" |
The rule macro was changed to quote the names of functions in function call expressions. This is a change from the old rule macro. I used to return function objects from the
operation
function, and now all my code is broken.This was not a backward-compatible change. I believe the following code should return true:
The text was updated successfully, but these errors were encountered: