Re: Storing data and code in a Db with LISP-like interface
Date: 21 Apr 2006 02:38:56 -0700
> Thanks for the above info. It seems the focus of Prolog and my db (with
> LISP-like interface) are quite different (at least at this time). While
> Prolog's primary focus seems to be deducing answering based on
> questions and data stored in linked lists; the focus of the
> experimental db is to provide the most flexible method of representing
Prolog is not based on linked lists, it is based on something very different namely "facts" and "rules" these give rise to incredible flexibility and power.
I encourage you to at least take a good look at Prolog and LISP. You may be able to get off to a flying start by begining with one of them and extending? They'll at least give you some very interesting ideas and I reckon you'll have fun - I know I did.
They both have some real limitiations like being memory based and Prolog lacks procedural abilities to bail it out of trouble (as we do with SQL when we use some procedural language with it) but for flexibility Prolog and LISP win.
> I believe I have already surpassed RM. And as far as I can
> tell, linked-lists are not even as flexible as RM.
I agree linked-lists aren't as powerful as the RM but LISP and Prolog
are not merely about lists.
Both Prolog and LISP can represent information and indeed knowledge
well beyond the RM, that's why they are popular with the ai community!
Both Prolog and LISP can represent information and indeed knowledge well beyond the RM, that's why they are popular with the ai community!
> IMO, all else is
> built upon the ability to store/recall things. Any
> weakness/inflexibility at the foundation eventually leads to
> limitations in applications built on top of it. This is the case with
> RM/SQL. This will also be the case with LISP and Prolog. However, I am
> sure currently and for years to come, Prolog/LISP will have better
> algorithm for processing whatever data it can store/recall from linked
> Below is a simple example that stores a person named John who likes
> Mary and then finds who John likes. Could you or someone familiar with
> Prolog show how to do this. Later I would like to extend the example to
> distill Prolog's fundamental forte (and possible weakness in
> representing things).
> // Create type person.
> (create type instance (new))
> (create (it) name (findElseAdd name instance 'person'))
> // Create a person named John.
> (create person instance (new))
> (create (it) name (findElseAdd name instance 'john'))
> // Create a person named Mary.
> (create person instance (new))
> (create (it) name (findElseAdd name instance 'mary'))
> // Create verb instance like.
> (create verb instance (new))
> (create (it) name (findElseAdd name instance 'like'))
> // Create John likes Mary.
> (create john like mary)
> // Who does John like?
> // Displays mary.
> (msgbox (select john like *))
To do this in Prolog you need these 2 lines of code:-
2. ?- likes(john,X).
Line 1 is a fact clause and 2 is a goal which solves for "X".
To match your example more closely we could have:-
1. person(john). 2. person(mary). 3. likes(john,mary). 4. likes(X,Y) :- person(Y).
This says john and mary are person's and when one likes they must like a person but those lines (1,2,4) are probably superflous.
In Prolog you can easily add more facts and rules about all sorts of
likes(john,mary) likes(bill,mary). likes(jim,mary). likes(jack,mary). likes(mary,peter). studies(mary,ai). studies(john,ai). studies(jones,piano).
course(ai,fun). course(art,funky). parent(mary,jodie). parent(mai,mary). parent(granny,mai).
grandparent(X,Z) :- parent(X,Y), parent(Y,Z). ..more simple rules and facts ...
IMHO I think you owe it to yourself to take a closer look at Prolog and
Cheers. Received on Fri Apr 21 2006 - 11:38:56 CEST