Re: Homoiconic relational programming language

From: Sampo Syreeni <decoy_at_iki.fi>
Date: Thu, 8 Apr 2010 09:18:50 -0700 (PDT)
Message-ID: <390406f9-1c18-428b-96ef-140e51d1cfe8_at_z11g2000yqz.googlegroups.com>


On Mar 8, 1:14 pm, Nilone <rea..._at_gmail.com> wrote:

> Any thoughts, ideas, references - I'd like to hear them.

(First, sorry about my latest flood, it's been a while since I last read the group.)

I've been thinking about this a lot, originally because of the dreaded "object-relational mismatch". What is it precisely that causes it? And I think I have at least a partial answer. The control and program flow, record at a time orientation of OO makes for irregular access across data types, whereas relational is all about controlled, breadth first structuring.The temporally linear control flow and the presence of uncontrolled side effects on individual records/objects is also very different from the set oriented, transaction view of the DB community.

That's why I think the best current substrate for relational processing would probably be some LISP derivative, e.g. Haskell. There we have the proper high level constructs to deal with lists and sets. With a little bit of syntactic sugar, bona fide relations should be easy enough to embed. Side effects, they could be avoided altogether as in SQL (when used purely as a DML), or they could be treated transactionally and in a principled manner (e.g. via Haskell's monads). And most of all, the macro facility of LISP dialects is strong enough to actually mutate your accesses into something an RDBMS could chew efficiently (i.e. entire groups of monadic functions could be transparently turned into a single transacted MERGE under Oracle, without the module microstructure and call flow of the code getting into way; good riddance to cursor loops, which are perhaps the single worst offender in OR/M).

Of course this sort of thing would also need some interface innovation on the RDBMS side. For example, the DBMS sees this sort of client as someone who wants to do a whole lot of very complicated, set oriented processing, involving literal data. Under SQL a typical state save would probably contain thousands to tens of thousands of individual updates within a single transaction, to multiple tables, preferably specifying related data together as short-lived temporary relations which might have little to do with the underlying schema. Neither SQL nor the rest of the data sublanguages fare well with this sort of thing. E.g. have you ever tried to enforce even an arbitrary two-to- one attribute functional dependency over a single table in one SQL clause? The simplest way to do that would be to declare a literal relation with the mapping and then merging it to the destination table, but that facility just ain't there with SQL or any other database language I know of.

Still, I think if somebody was to pull this thing off, that'd be a *huge* productivity *and* performance boost. Precisely because the homoiconicity could be leveraged to its fullest, and because once you're into the pure data, relational mindset, there are some exceedingly powerful programming idioms floating around for that. They go under the heading of complex event processing, truth maintenance/ belief revision systems (very relevant for the view update problem, btw), and at least one early system (whose name I cannot remember) which implemented pretty much all of the online relational primitives which have been proposed in the recent past (memorex, no, cerebrex, no, it was something vaguely to that effect).

--
Sampo
Received on Thu Apr 08 2010 - 18:18:50 CEST

Original text of this message