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

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sat, 29 Apr 2006 23:29:33 +0200
Message-ID: <4453dab2$0$31650$e4fe514c@news.xs4all.nl>

Neo wrote:
> ...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.

The underlying stuff is all bits. I am glad I don't have to deal with them directly.

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

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

Bob, anything to say about prologs data-dependence? (Maybe I made it to Bobs killfile - dunno). I have read some of Date's books.

Kidding aside - it's a strange statement about a system with code-data equivalence.

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

>
> Exactly what it says :)

It doesn't make sense.

>>>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)

Without further requirements you just need to put some periods at the appropriate spots.

>>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.

Changing, yes. Yet they need to be clear.

>>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.

No.

> My requirement is how to
> best meet dynamic requirements (ie like those of an andriod).

Yes. So I'll repeat:
It is important to find a good way of stating requirements. Up to now I don't think you have found it. Received on Sat Apr 29 2006 - 16:29:33 CDT