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
Here, as in other approaches to solving #45, there's an issue with "handing back" any result we would generate at the framework level to the user. Part of this seems related to the inability to distinguish a fact's identity given syntax alone. For #45 we may resolve this by requiring users to supply an attribute that acts as a kind of callback. Seems we need to know what attribute to assign the list value to, and the user needs to know that as well so they can grab it.
Anyway. These are merely thoughts for now, but exciting ones given that the resolution for #45 may entail dynamic rule generation. Combined with the rule-registry we already have, metaprogramming with rules seems not so far out of reach.
The text was updated successfully, but these errors were encountered:
While brainstorming solutions for #45 I thought about using rules to program rules.
Suppose we had the following metarule that operates over something like our DSL's AST:
Here, as in other approaches to solving #45, there's an issue with "handing back" any result we would generate at the framework level to the user. Part of this seems related to the inability to distinguish a fact's identity given syntax alone. For #45 we may resolve this by requiring users to supply an attribute that acts as a kind of callback. Seems we need to know what attribute to assign the list value to, and the user needs to know that as well so they can grab it.
Anyway. These are merely thoughts for now, but exciting ones given that the resolution for #45 may entail dynamic rule generation. Combined with the
rule-registry
we already have, metaprogramming with rules seems not so far out of reach.The text was updated successfully, but these errors were encountered: