-
Notifications
You must be signed in to change notification settings - Fork 127
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
copy_term/3 kind of removes constraint #1272
Comments
Conceptually, copy_term(Term, Copy, Gs) :- '$term_attributed_variables'(Term, Vs), findall(Term-Gs, ( phrase(gather_residual_goals(Vs), Gs), '$delete_all_attributes'(Term) ), [Copy-Gs]). We assume here that a nonterminal The reason to use Also, we assume the presence of an internal predicate called |
For the moment, the defective |
Regarding |
It seems to be less resource consuming to put |
|
Yes, and on a general note, I would like to add that it is highly desirable to keep as much code as possible in Prolog, because only then will there be the greatest motivation to actually improve the performance of the Prolog code. Putting it all in Rust is tempting, but should be seen as a last resort: The key design point is finding exactly the smallest set of primitives that absolutely must be placed in Rust for acceptable performance, or to enable bootstrapping. In this concrete case, it seems preferable to implement the internal Rust-based |
What about the deeper question, whether or not
|
I think |
The idea of
copy_term/3
is to leave the 'constraint store' completely unmodified. But this is what happens:The text was updated successfully, but these errors were encountered: