Re: [boost] [castor] Interest in Logic Paradigm for C++ ?
Hi Roshan! I'm a newbie C++ programmer, but I have experience designing logic programming languages (e.g., miniKanren in Scheme). I'm curious why Castor doesn't implement full unification. Is this because of the historical relationship between Castor and Leda? There are many interesting logic programs that can't be written naturally without full unification. (My dissertation contains many such programs, so I'm biased!) Many people in the logic programming community don't consider Mercury to be a real logic programming language precisely because it doesn't support full unification. Is Castor aiming towards the Mercury model, with the idea of adding mode annotations, etc., in the future? That might be a nice sweet spot for the Boost libraries. Otherwise, I would prefer to see full unification in any official Boost logic programming language/library. How hard would it be to add full unification to Castor, or to at least allow full unification as an option? --Will
Hi Will, On Fri, 07 May 2010 10:14:30 -0600, William Byrd <webyrd@gmail.com> wrote:
I'm a newbie C++ programmer, but I have experience designing logic programming languages (e.g., miniKanren in Scheme).
Very cool. BTW, some aspects of Castor's design fell in place while I was reading your book "Reasoned Schemer". It surprises me as I could never see any direct co-relation between what I was reading and what I implemented. :-) Perhaps it might be more evident to you.
I'm curious why Castor doesn't implement full unification.
It can be implemented in C++ but would impact the performance of all LP code even if did not require full semantics. In order to support dynamically binding lrefs that were not already bound to each other, the only technique I could think of was ... to add an extra level of indirection inside lref to point to its data. Basically anytime you read or modify the another level of dereferencing would be required internally. So I decided to defer supporting these semantics to some point in the future... when either this limitation proves too severe (making the performance issue acceptable), or until a way to implement these semantics without hurting performance becomes apparent. I think I should address this topic in the design document.
There are many interesting logic programs that can't be written naturally without full unification. (My dissertation contains many such programs, so I'm biased!)
I fully agree with you. Personally, I would also love to see this happen without impacting performance. I was hoping to investigate this further with help from some LP expert. I would like to study these examples you mention.
Is Castor aiming towards the Mercury model, with the idea of adding mode annotations, etc., in the future? That might be a nice sweet spot for the Boost libraries.
Not sure what you mean by mode annotations. I am not familiar with Mercury.
Otherwise, I would prefer to see full unification in any official Boost logic programming language/library. How hard would it be to add full unification to Castor, or to at least allow full unification as an option?
I don't have any ideas at the moment. If you have some promising suggestions (no hurry!) in that space I am willing to pursue them. -Roshan
participants (2)
-
Roshan -
William Byrd