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

>> ... the limiting consequence of nested linked list as the fundamental data structure, using non-data independent references, lack of complete normalization, inability to use functions (not function ouputs) as a parameters, meta-data, etc.
.
> Your eagerness to dismiss everything but your own product clouds your progress.

I don't dismiss, I demonstrate with examples :) Take from the results what you will.

> > nested linked list as the fundamental data structure
.
> Maybe under the hood it is. If so, this is a quite well hidden prolog implementation detail. Trees and other graphs are handled easily in prolog.

It isn't a matter of how well the underlying data structure is hidden. It is a matter of what the underlying data structure will allow one to represent in a general/flexible/systematic manner.

>> using non-data independent references
>
> What do you mean?

Have a conversation with Bob Badour or see Date's books.

>> lack of complete normalization [of things represented]
>
> What do you mean?

Exactly what it says :)

>> inability to use functions (not function outputs) as parameters, meta-data
>
>This is simply not true.

I could be wrong, so please demonstate the following in Prolog:

like (john, mary).
hate (john, bob)
opposite (like, hate)

> Hmm. Not much left of this list. Care to elaborate?

:)

>> Some of these cannot be realized in a static example but rather by observing how a methodology's steps to implement the next set of requirements are affected. Consistency/systamaticness in meeting progressive requirements become more of an issue in AI type apps (ie an andriod) which would continually face changing requirements.
.
> It is important to find a good way of stating requirements. Up to now I don't think you have found it.

:) You are expecting a static requirement. My requirement is how to best meet dynamic requirements (ie like those of an andriod). Received on Sat Apr 29 2006 - 21:43:52 CEST