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

>> items that ... will limit Prolog's ability to represent things in as general/flexible/systematic a manner as dbd for AI-type apps: 1) Inability to use functions (not function results) as parameters of other functions.
.
> I don't have the prolog skills to demonstrate it, but from what I've seen my guess is that this is quite easy for a skilled prolog programmer.

Hopefully someone more skilled than either of us from comp.lang.prolog can give us a definitive answer, but my guess is that either it isn't possible or will be very unsystematic.

>> etc. Consider what changes take place if the third fact is not
>> known/added until after the first two are known/stored/coded against.
>
> Raising the bar - as usual.

:) Reality is setting the bar, not me.

>> 2) Inability to normalize every thing that is represented. For example, the names of things. In Prolog, an atom and it's name are basically inseperable. Thus:
>
> ISTM you have a homegrown 'normalize' interpretation.

Read it as representing things with out redundancy. When RM users talk about 'normalization' they are only thinking about the first few forms and not aware that there are actually an infinite number. See p 291 of Date's Intro to Db Systems, 6th Ed, Chp 10, Further Normalizations.

>> 2a) Multiple names for a thing will not be represented systematically.
>
> Not by itself - that would be magic. If two names refer to one thing
> this should be told or inferrable.

I not talking about magic, but being systematic. Here is one was to create an atom with two names in Prolog:

person(john).
name(john, johnny).

Compare with dbd's which is more systematic:

(create person instance (new))
(create (it) name (word john))
(create (it) name (word johnny))
(select (it) name *)    // displays john, then johnny.

>> 2b) A thing with no name will have to be given a name anyway such as no_name. This is similar to the NULL problem in RM. Now the the andriod will think a thing's name is actually no_name unless additional rules are added. If handled as such, what if droid actually encounters something named no_name? And how to handle additional unnamed things? no_name2, no_name3, ...?
.
> I found this: http://gollem.science.uva.nl/SWI-Prolog/Manual/gensym.html Is that what you mean?

No. The link addresses how to generate no_name2, no_name3, etc but that is not the significant problem. When a system requires information that is missing (ie an atom requires the name of thing being represented), three-valued logic appears which is a major no no. See Chapter 20 of Date's Intro to Db Systems, 6th Ed.

>> 2c) Two atoms can't have the same name so the atoms for cat and person named mary might be mary_cat and mary_person and this leads to redundant data as shown below. I won't explain the pitfalls of redundancy as volumes have been written on it already with respect to data mgmt: cat (mary_cat). person (mary_person).
.
> Neither RM nor prolog have difficulties because people tend to name both cats and people mary. I can see that it poses a problem to a droid how to distinguish them if someone refers to mary. Heh - I've seen people making mistakes on this one. Context matters.

I don't believe two atoms can have the same name (ie mary), thus one might use mary_cat and mary_person. Now the cat in mary_cat is redundant information to cat in function name cat(mary_cat) and there is no systematic enforcement of the two. It is dependent on a user to make corrections in both (or multiple) places if mary_cat turns out to be a dog.

> 2d) It does not appear to me (or actually I didn't get to verify this via the example), that the name of an atom is not stored in Prolog's fundamental data representation methodology.

like(john, mary).
hate(john, bob).
opposite(like, hate).
?- current_predicate(like/2). Yes
?- current_predicate(neo/2). No

I don't think you have demonstrated anything relevant. Here is what current_predicate does according to one manual: Successively unifies Name with the name of predicates currently defined and Head with the most general term built from Name and the arity of the predicate. This predicate succeeds for all predicates defined in the specified module, imported to it, or in one of the modules from which the predicate will be imported if it is called. Received on Mon May 01 2006 - 03:40:55 CEST