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

From: Neo <neo55592_at_hotmail.com>
Date: 2 Apr 2006 18:53:54 -0700
Message-ID: <1144029234.495256.11540_at_u72g2000cwu.googlegroups.com>


> > Neo: ... experimental db that can store both data and code ...
>
> Lahman: My push back has to be: Why?

:) To approach the type of processing capability displayed by humans. While I will not achieve anything like that in my life time, manipulating code just like data allows solutions for some niche applications (AI-ish) that are impractical with existing tools.

> Lahman: Commercial DBMSes already provide storage and execution
> of stored procedures.  RAD IDEs already store everything in the DB.
> Source control systems already exist for managing code
> without requiring the tediousness of your example code.

Let me qualify what I mean by "storing code in a db". The code must be stored in its elemental form (not as a chunk or blob) and can be created, selected, updated, deleted, etc just as any other data. In addition, code should be normalized just like regular data. The real test, can one store code that can either modify itself or create new code (which can itself create new code, and so on) using its standard Data Manipulation Language (DML)? While I can't fully accomplish this yet, I can show a crude example that creates and modifies a one line query/code to determine if john's color is blue, as shown below:

// Assume person john has already been entered into db
// and his color is blue.

// Create a variable named 'myVar' which will refer to a query/code.
(create variable instance (new))
(create (it) name (findElseAdd name instance 'myVar'))

// Create query/code to verify john's color is blue
(select john color blue)

// Let myVar refer to above query/code.
(create myVar

        refersTo
        (select (select (select * name (select * symbol 'select')))
                john
                color
                blue))

// Execute above query/code and display result.
// Displays "john color blue" meaning db stores this fact.
(msgbox (execute (select myVar refersTo *)))

// Modify above query/code to find "john's color is pink".
(update (select (select (select * name (select * symbol 'select')))

                john
                color
                blue)
        pink)

// Execute modified query/code.
// Displays nothing because the modified query
// does not return anything.

(msgbox (execute (select myVar refersTo *)))

Also, if one were to change the string related to the name of the type color from the 'color' to 'colour', the original query (select john color blue) would still function in the experimental db, where as it probably would not in RM. Someone would need to manually, update the spelling in stored procedures and recompile them. Received on Mon Apr 03 2006 - 03:53:54 CEST

Original text of this message