Skip to content
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

Option to add AST element from string. #3

Open
namcsi opened this issue Sep 4, 2023 · 0 comments
Open

Option to add AST element from string. #3

namcsi opened this issue Sep 4, 2023 · 0 comments

Comments

@namcsi
Copy link
Collaborator

namcsi commented Sep 4, 2023

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.

ast_operation(
    add(number(init_number,0));
    add(terms(init_terms,0,number(init_number)));
    add(function(init_function,initially,terms(init_terms)));
    add(symbolic_atom(init_symbol,function(init_function)));
    add(literal(init_literal,"pos",symbolic_atom(init_symbol)));
    add(rule(init_rule,literal(init_literal),body_literals(init_body_literals)))).

ast_operation(add(statements(S,X+1,rule(time_rule))))
    :- program("base",_,statements(S)), max_statement_index(S,X).

With the proposed feature, such an ast operation could be more succincly be described by the following rules:

ast_operation(@add_from_string("initially(0).",rule(time_rule))).

ast_operation(add(statements(S,X+1,rule(time_rule))))
    :- program("base",_,statements(S)), max_statement_index(S,X).

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.

ast_operation(
    add(variable(time_variable(R),"T"));
    add(terms(time_terms_var(R),0,variable(time_variable(R))));
    add(function(time_function_var(R),time,terms(time_terms_var(R))));
    add(symbolic_atom(time_symbol_var(R),function(time_function_var(R))));
    add(body_literal(time_body_literal_var(R),"pos",symbolic_atom(time_symbol_var(R))));
    add(body_literals(B,MAX+1,body_literal(time_body_literal_var(R))))
    )
:- rule(R,_,body_literals(B)), max_lit_index(B,MAX).

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:

ast_operation(
    @add_from_string("time(T)", body_literal(time_body_literal_var(R)));
    add(body_literals(B,MAX+1,body_literal(time_body_literal_var(R))))
    )
:- rule(R,_,body_literals(B)), max_lit_index(B,MAX).

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant