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
Based on example meta-encodings so far, it seems that meta-encoding have a tendency to be a bit verbose due to the fact that, when adding a new branch in the AST, one needs to create a fact for each intermediate node. While this verbosity is unavoidable in many cases, perhaps we could add some facility which creates an ast branch from it's string representation when it's string form is known a priori. It remains to be seen if this would be practical and/or necessary; the idea is described in more detail below.
Take for example the telingo transformer in examples/telingo/transformer.lp. It has a few rules like the following, which in effect just adds a single fact initially(0). to the AST of the program.
The @add_from_string would be implemented as a clingo external function (using the reification functionality of renopro), and would expand to the appropriate add/1 function terms which add the desired ast branch as the child of the rule(time_rule) identifier, all the while taking care of generating unique id-s.
One also sometimes needs to parametrize the identifiers of an added ast branch on one or more variables bound in the body of a meta-rule, in order to maintain unique identifiers. One such example is the following one in examples/telingo/transformer.lp.
This could also be handled by the @add_from_string external function without any further modifications, by simply using a variable in the argument that gives the root of the branch:
Note that the second argument to the external function body_literal(time_body_literal_var(R))) also serves to disambiguate what type of node the first argument "time(T)" represents (in this case, a body literal).
(Note to self: I believe this parsing context cannot explicitly be passed to the clingo parser, but one could do something a bit hacky with format strings in the external python function, like parse_string(f":- {string}", lambda node: reify(node)) in the case of body literals. One would however need to discard the superfluous reified facts generated).
Implementing this functionality would require some modification to the reification functionality to customize the generated id-s a bit more than is currently possible.
The text was updated successfully, but these errors were encountered:
Based on example meta-encodings so far, it seems that meta-encoding have a tendency to be a bit verbose due to the fact that, when adding a new branch in the AST, one needs to create a fact for each intermediate node. While this verbosity is unavoidable in many cases, perhaps we could add some facility which creates an ast branch from it's string representation when it's string form is known a priori. It remains to be seen if this would be practical and/or necessary; the idea is described in more detail below.
Take for example the telingo transformer in
examples/telingo/transformer.lp
. It has a few rules like the following, which in effect just adds a single factinitially(0).
to the AST of the program.With the proposed feature, such an ast operation could be more succincly be described by the following rules:
The
@add_from_string
would be implemented as a clingo external function (using the reification functionality of renopro), and would expand to the appropriate add/1 function terms which add the desired ast branch as the child of therule(time_rule)
identifier, all the while taking care of generating unique id-s.One also sometimes needs to parametrize the identifiers of an added ast branch on one or more variables bound in the body of a meta-rule, in order to maintain unique identifiers. One such example is the following one in
examples/telingo/transformer.lp
.This could also be handled by the
@add_from_string
external function without any further modifications, by simply using a variable in the argument that gives the root of the branch:Note that the second argument to the external function
body_literal(time_body_literal_var(R)))
also serves to disambiguate what type of node the first argument"time(T)"
represents (in this case, a body literal).(Note to self: I believe this parsing context cannot explicitly be passed to the clingo parser, but one could do something a bit hacky with format strings in the external python function, like
parse_string(f":- {string}", lambda node: reify(node))
in the case of body literals. One would however need to discard the superfluous reified facts generated).Implementing this functionality would require some modification to the reification functionality to customize the generated id-s a bit more than is currently possible.
The text was updated successfully, but these errors were encountered: