(Sorry, meant to reply to the list, also)
Thanks, great information and sounds overall feasible, too. > > -----Original Message----- > From: w...@dualtech.com.pl [mailto:w...@dualtech.com.pl]On Behalf Of Wojciech > Kaczmarek > Sent: 19 September 2011 18:06 > To: Jukka Tuominen > Subject: Re: [racket] Seamless Prolog integration > > > Hi. > > > I can shed some light on this from my little experience with Racklog and a > bit broader with using/integrating various Prologs. Excellent :) I could hardly scratch the surface by myself. > > > On Mon, Sep 19, 2011 at 13:22, Jukka Tuominen > <jukka.tuomi...@finndesign.fi> > wrote: > > > Hi, > > inspired by the Datalog discussion, I'd like to understand better what > kind > of challenges I could expect when trying to create a proof-of-concept > about > integrating prolog-type-of functionality to Liitin. This would also > serve > as > an example/ stepping stone for others to create something more useful. > Since > Prolog is a bit out of this world, I would propably ask wrong questions, > so > I hope the following will give enough information to understand the objectives. > > 1) Prolog (type-of) functions should be used as hidden subroutines and > you > could call them as racket functions (~ #lang racket notation) > > > > Once you load your querying predicates & facts, you can wrap typical queries > in regular Racket functions. Great. So, predicates are like racket expressions? ... > > 2) No particular prolog engine should be running and waiting for prolog-specific interactions. If such engine is needed (beyond plain functions), it should be initiated and terminated automatically to meet > 1) > > > > The initialization you need is just loading your predicates. Also see answer > for q. 4. > > > > 3) The knowledge need to be stored as static/persistent objects (Liitin > objects). Again, rather than keeping them in memory, you could call them > as > needed. > > > > This is common and very practical requirement, but well, most Prologs provide reasoning engine but don't include storage engine, so you're on your > own. Datalog & Racklog seem to be in this category as well. There are couple > of solutions here. The most obvious idea for Racklog is that you don't put > your concrete data in facts, but you code your predicates so they pull your > data from SQL, serialized Racket structures or whatever. The other solution > is that you initially convert your data from external format into calls of > %assert! which build up your Racklog database. You can do the latter for Datalog as well. ... and facts are like input you give to the expression, right? Such as (predicate facts) ? If this is the case, then Liitin should suit perfectly to store both. For example expression ns:sqr could be saved into db as: (lambda (x) (* x x)) and ns:data could be saved as: 5 so (ns:sqr ns:data) evaluates to 25. All db operations are handled transparently (thanks to Eli's help). Could you, by any chance, give me some simplest examples of the predicate and fact definitions so I could understand the basic format of each and even try to test them in practice? I've looked at Jay's Datalog documentation and eventhough it seems within reach, I can't quite capture the possible adaptation to Liitin. Now, having looked at the Racklog, it appears more Racket- and Scheme-like, which seems more suitable for the 'top-level Scheme' objective. That is, being able to call (and share) data and functions in common Scheme, eventhough underlaying implementions may vary. Hmm, should I call it Common Scheme :) > > > 4) It should be possible to have several, independent knowledge bases > saved > in the same (Liitin) database. > > > I can't speak for the Racklog & Datalog authors, but AFAIK there's no such > separation of knowledge bases. You should just make sure that your predicates don't refere to each other. There should be no problem, then. And even better; if you do want to mix them, that sounds easy, too. > > > > > There's also completely different possibility: having someone with Prolog > skills you could build querying service on the top of a standalone Prolog > implementation. Free SWI-Prolog has production-quality embedded web server. > I used it once to host a service answering specific queries via JSON-like > interface from a Python application. Still you have a task as in q. 3: how > to feed the stored data into Prolog. We used SWI's ODBC library to dynamically get what we needed from existing data warehouse; it was fine enough. > > > Of course it is multiplying the technologies, but well, sometimes the power > of Prolog-like querying is what one needs. YMMV.. Liitin is based on Racket engine, so extending it is the way to go in this case. Neil, happy? :) "...Racket's linguistic malleability means that, once introduced to an idea originated in some other language, there's a good chance that one can then explore that idea further within Racket." br, jukka > > > > > best, > > > wojtek > > > > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
