Re: Storing data and code in a Db with LISP-like interface

"Neo" <neo55592_at_hotmail.com> wrote in message news:1146513452.864955.15150_at_i40g2000cwc.googlegroups.com...

> But on a related note, as the original and serveral other posts
> indicated, an app/android using dbd can create a new function (ie
> createWRR or getRoot) on-the-fly, at run-time simply by adding data to
> the db using the existing functions such as create, select, etc. The
> app/andriod can then use the new function in yet another new function
> and so on, all at run-time. Can Prolog or LISP do similar? Since there
> is still a lot of development to do in this area, I can only demo
> simple functions at this time.
>

Yes, Prolog can assert new facts and relationships to allow entirely new deductions and deduction models. That was its original intent, as a mechanism for representing knowledge so that the system could display machine-learning behaviors, which Prolog systems do quite well.

I find it fascinating that your model is so mathematically frail that you needed to add statements to the compiler in order to support simple mechanisms, rather than simply defining a function in the language.

I have a challenge for you.

Assume that you want to represent the following information:

Tony has a dog and a bird
Joe has a bird
Mary has a dog
Bird owners enjoy a hot bath
Dog owners that are not bird owners enjoy taking long walks Dog owners prefer cold showers
On Tuesday, Dog owners who are also bird owners buy groceries On all other days, bird owners who are not dog owners buy groceries

In this case, most ordinary programming languages struggle. Prolog shines. Every statement above is a single statement in Prolog. Finding people who like cold showers is simple. Finding people who enjoy both a hot bath and prefer a cold shower is also simple. Finding people who take long walks is simple.

I'm sure that most or all of these items is also quite doable in your db language. The point is that your language does not exceed Prolog. If you are lucky, you are on par with Prolog in many cases. For that, I applaud you. It is difficult to create a KR mechanism that is flexible. That you did it without using formal logic or a grounding in horn calculus is quite impressive. But it doesn't make your system any better, and in fact, it is unlikely to exceed Prolog in design and elegance because simple equations cannot be easily reduced. Prolog succeeds in this area because of its simplicity, not its superiority.

As I said before, ultimate flexibility yeilds almost nothing. While Prolog can represent everything that your system can, history did not prove it to be ultimately successful. Clearly, the problem isn't the lack of flexibility in representing knowledge... now is it?

-- 
--- Nick Malik [Microsoft]
    MCSD, CFPS, Certified Scrummaster
    http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not 
representative of my employer.
   I do not answer questions on behalf of my employer.  I'm just a 
programmer helping programmers.
--