25 ms·

What are the trade offs of embedding a Prolog interpreter versus having a library that implements prolog logic without having to have another language. Are the

What are the trade offs of embedding a Prolog interpreter versus having a library that implements prolog logic without having to have another language. Are there any high quality prolog as a library implementations in languages such as Rust, C++, Java, Go?

exDM69 5y ago
> What are the trade offs of embedding a Prolog interpreter versus having a library that implements prolog logic without having to have another language. A library that implements Prolog logic is an interpreter. The difference here is that Prolog source code is passed in as a string as opposed to having an embedded domain specific language where you construct the abstract syntax tree. Go is a very simple language and it doesn't have the kind of metaprogramming facilities that are typically used for creating embedded DSLs. Hence it's a reasonable choice to just have a parser and pass in the logic code as a string. There's probably a way to pass in the AST as well but it may not be very ergonomic. Parsing the source and constructing the AST isn't very expensive and it's only done once per program, so the runtime cost isn't huge. There are Prolog and Prolog-like embeddable interpreters and logic programming systems for many other prorgamming languages, including Rust, C++ and Java. The best known ones are Clojure's core.logic (based on the logic interpreter in the SICP book) and Minikanren.
- tgv 5y ago
  Indeed. Text is "unreasonably efficient" in this case. Passing a struct is easy enough in go, but that's all it can do for you. So you'd have to pass arguments like PLClauseList{PLLoadClause{...}, ..., PLFact{Head: PLAtom{"human"}, Arguments: PLArgList{PLAtom{"socrates"}}}, ...}. Unwieldy, unreadable, and hard to edit.
- vvern 5y ago
  There are advantages to embedding. You can retain the host language type system and and object model. If you have a great query language and model but have to write a ton of code to marshal back and forth, it might not be adding that much value (classic impedance mismatch). While go’s compile time metaprogamming is virtually non-existent, it’s runtime metaprogramming with reflection is more or less complete. There’s a runtime cost to using it, but that can be mitigated. See https://github.com/cockroachdb/cockroach/tree/master/pkg/sql/schemachanger/rel https://github.com/cockroachdb/cockroach/tree/master/pkg/sql... for a reflection-driven, embedded logic query language in go that achieves pragmatic goals of writing logic queries over data structure graphs at reasonable performance and pretty good expressibility.
aarroyoc 5y ago
IMHO you loose a lot of expresiveness. Real Prolog code is not just simple rules and facts. They can be more complex than that. For example, in my case, I'd like to use DCGs a lot, which are a bit difficult to translate using "normal languages" constructs. Many Prolog systems implement DCGs with Prolog macros because Prolog is homoiconic, which most normal languages aren't (Lisp is homoiconic too). Also "logic" arithmetic (clpz, clpfd,...) is not the one that comes with normal languages and that breaks a lot of logical properties. Doing the sum of two variables in Java side will not respect logical properties. Standard is/2 in Prolog is also bad, but at least you can replace it with #= and that's it.
Avshalom 5y ago
I've never used it but for Java there's https://gitlab.com/pika-lab/tuprolog/2p-in-kotlin https://gitlab.com/pika-lab/tuprolog/2p-in-kotlin ( documentation seems to be lagging but here's the 3.3 manual https://gitlab.com/pika-lab/tuprolog/2p/-/wikis/uploads/d67e89c81da28d33cf7c8241cc35cab2/tuprolog-guide-3.3.0.pdf https://gitlab.com/pika-lab/tuprolog/2p/-/wikis/uploads/d67e... ) And specifically for Javascript there's http://tau-prolog.org/ http://tau-prolog.org/ Also pretty much every lisp that's gotten past toy stage has a Prolog implementation Although both Sicstus and SWI have strong Java and C(++) interop https://sicstus.sics.se/sicstus/docs/latest4/html/sicstus.html/Mixing-C-and-Prolog.html#Mixing-C-and-Prolog https://sicstus.sics.se/sicstus/docs/latest4/html/sicstus.ht... https://www.swi-prolog.org/pldoc/doc_for?object=packages https://www.swi-prolog.org/pldoc/doc_for?object=packages
jfmc 5y ago
Some Prolog systems (like Ciao Prolog https://github.com/ciao-lang/ciao/blob/master/core/lib/foreign_interface/embedding_example/test.c https://github.com/ciao-lang/ciao/blob/master/core/lib/forei...) implement bidirectional foreign interfaces. Once you have C bindings it is easy to write bindings from Rust, C++, or any other language (that can interoperate with C). I give here some details about Ciao because this is the system I know better but it should be similar for other popular Prolog implementations. The tradeoffs depend on the complexity of the Prolog code and your needs for performance and features: pure LP, Prolog (search+unification+cut), garbage collection, dynamic database updates, constraint domains, etc. The Ciao Prolog engine is around 300-400KB. Adding a few libraries, compiler, etc. it goes to 2MB. Naive Prolog systems can be one order of magnitude smaller at the cost of sacrificing ISO compatibility, performance, etc. Note that "performance" can be very misleading. Some Prolog programs may run particularly fast in some Prolog system and very badly in others.

exDM69 5y ago

> What are the trade offs of embedding a Prolog interpreter versus having a library that implements prolog logic without having to have another language. A library that implements Prolog logic is an interpreter. The difference here is that Prolog source code is passed in as a string as opposed to having an embedded domain specific language where you construct the abstract syntax tree. Go is a very simple language and it doesn't have the kind of metaprogramming facilities that are typically used for creating embedded DSLs. Hence it's a reasonable choice to just have a parser and pass in the logic code as a string. There's probably a way to pass in the AST as well but it may not be very ergonomic. Parsing the source and constructing the AST isn't very expensive and it's only done once per program, so the runtime cost isn't huge. There are Prolog and Prolog-like embeddable interpreters and logic programming systems for many other prorgamming languages, including Rust, C++ and Java. The best known ones are Clojure's core.logic (based on the logic interpreter in the SICP book) and Minikanren.

tgv 5y ago
Indeed. Text is "unreasonably efficient" in this case. Passing a struct is easy enough in go, but that's all it can do for you. So you'd have to pass arguments like PLClauseList{PLLoadClause{...}, ..., PLFact{Head: PLAtom{"human"}, Arguments: PLArgList{PLAtom{"socrates"}}}, ...}. Unwieldy, unreadable, and hard to edit.
vvern 5y ago
There are advantages to embedding. You can retain the host language type system and and object model. If you have a great query language and model but have to write a ton of code to marshal back and forth, it might not be adding that much value (classic impedance mismatch). While go’s compile time metaprogamming is virtually non-existent, it’s runtime metaprogramming with reflection is more or less complete. There’s a runtime cost to using it, but that can be mitigated. See https://github.com/cockroachdb/cockroach/tree/master/pkg/sql/schemachanger/rel https://github.com/cockroachdb/cockroach/tree/master/pkg/sql... for a reflection-driven, embedded logic query language in go that achieves pragmatic goals of writing logic queries over data structure graphs at reasonable performance and pretty good expressibility.

aarroyoc 5y ago

IMHO you loose a lot of expresiveness. Real Prolog code is not just simple rules and facts. They can be more complex than that. For example, in my case, I'd like to use DCGs a lot, which are a bit difficult to translate using "normal languages" constructs. Many Prolog systems implement DCGs with Prolog macros because Prolog is homoiconic, which most normal languages aren't (Lisp is homoiconic too). Also "logic" arithmetic (clpz, clpfd,...) is not the one that comes with normal languages and that breaks a lot of logical properties. Doing the sum of two variables in Java side will not respect logical properties. Standard is/2 in Prolog is also bad, but at least you can replace it with #= and that's it.

Avshalom 5y ago

I've never used it but for Java there's https://gitlab.com/pika-lab/tuprolog/2p-in-kotlin https://gitlab.com/pika-lab/tuprolog/2p-in-kotlin ( documentation seems to be lagging but here's the 3.3 manual https://gitlab.com/pika-lab/tuprolog/2p/-/wikis/uploads/d67e89c81da28d33cf7c8241cc35cab2/tuprolog-guide-3.3.0.pdf https://gitlab.com/pika-lab/tuprolog/2p/-/wikis/uploads/d67e... ) And specifically for Javascript there's http://tau-prolog.org/ http://tau-prolog.org/ Also pretty much every lisp that's gotten past toy stage has a Prolog implementation Although both Sicstus and SWI have strong Java and C(++) interop https://sicstus.sics.se/sicstus/docs/latest4/html/sicstus.html/Mixing-C-and-Prolog.html#Mixing-C-and-Prolog https://sicstus.sics.se/sicstus/docs/latest4/html/sicstus.ht... https://www.swi-prolog.org/pldoc/doc_for?object=packages https://www.swi-prolog.org/pldoc/doc_for?object=packages

jfmc 5y ago

Some Prolog systems (like Ciao Prolog https://github.com/ciao-lang/ciao/blob/master/core/lib/foreign_interface/embedding_example/test.c https://github.com/ciao-lang/ciao/blob/master/core/lib/forei...) implement bidirectional foreign interfaces. Once you have C bindings it is easy to write bindings from Rust, C++, or any other language (that can interoperate with C). I give here some details about Ciao because this is the system I know better but it should be similar for other popular Prolog implementations. The tradeoffs depend on the complexity of the Prolog code and your needs for performance and features: pure LP, Prolog (search+unification+cut), garbage collection, dynamic database updates, constraint domains, etc. The Ciao Prolog engine is around 300-400KB. Adding a few libraries, compiler, etc. it goes to 2MB. Naive Prolog systems can be one order of magnitude smaller at the cost of sacrificing ISO compatibility, performance, etc. Note that "performance" can be very misleading. Some Prolog programs may run particularly fast in some Prolog system and very badly in others.