[racket] FW: Seamless Prolog integration

(Sorry, meant to reply to the list, also)


Thanks, great information and sounds overall feasible, too.

>
> -----Original Message-----
> From: wk at dualtech.com.pl [mailto:wk at 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.tuominen at 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
>
>
>
>