Replies: 2 comments 6 replies
-
As you mentioned, one of the solutions is to have additional, auxiliary predicates, with some filter argument(s). As the filter always needs to be specified somewhere, a possible alternative is to use parametric objects where the parameter(s) are either variables (at message sending time) or found to the filter(s). Something like: :- object(config(_Compiler_), ...).
satisfy(...) :-
compiler::c_compiler(_Compiler_),
...
:- end_object. This could then be used as either Both solutions have the same expressive power but it's not clear without more details which one would be preferable from a software engineering perspective. The parametric object solution may work best when the filter(s) apply to multiple predicates. |
Beta Was this translation helpful? Give feedback.
-
With parametric objects/categories based solution, you would likely use a parameter per filter. You could then provide common configurations (with fixed compiler, make, ... tools) by extending the parametric object and bounding the parameters. Something like: :- object(config(_Compiler_, _Make_, ...), ...).
...
:- end_object.
:- object(gnu_config, extends(config(gcc, gmake, ...))).
...
:- end_object. Regarding aliases, have you already read: https://logtalk.org/2020/01/08/object-and-predicate-aliases.html |
Beta Was this translation helpful? Give feedback.
-
Is there any idiomatic way (or a tried technique) for specifying filters for answers for certain predicates in particular objects?
Suppose I have some predicate that uses other non-deterministic predicates defined across my codebase that return zero or more answers. This generates all possible configuration parameters for building packages (different compilers, build tools, library artifacts, etc.). Applying all these answers is helpful in some cases as it generates the entire matrix. However, more often than not, we need to limit it to certain answers to narrow it down.
Let's say we have a predicate
compiler::c_compiler(Compiler)
, and we want to ensure that the code that uses this predicate only gets answers that areclang
, something [superficially] similar to this:I can probably do a lot of it manually, rewriting each such predicate to have a "filtering" version of the predicate instead of the real one (that would compare its notes with the asserted filter [hand-wavy here]) and having the actual predicates defined in its "internal" version. Maybe even with some help of term expansion. But before I do so, I just wonder if such a case has been worked on before and maybe there's something to learn from.
As always, thank you very much!
P.S. I hope my sleep deprivation is not affecting the quality of this question too much :)
Beta Was this translation helpful? Give feedback.
All reactions