Re: Homoiconic relational programming language
Date: Fri, 09 Apr 2010 13:47:57 GMT
Message-ID: <heGvn.1181$z%6.1105_at_edtnps83>
Sampo Syreeni wrote:
> 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).
> --
This is a provocative post and even if the language is loose it echoes my attitude. Regarding the "mismatch", I'd say it is clearly a symptom of a certain human frailty that to paraphrase one of the big early thinkers tempts us to imagine that submarines can swim.
Theorists in most areas of IT like to compare their practical efforts against some model or other but it is the mixing up of those chosen 'models' that sets the stage for the mismatch. The motive for the comparison is a good one because without it we have no context to distinguish different models. The Turing machine is one model and the relational machine is another model (possibly it should be called the Codd machine, if so then I'm talking only about the 'Codd version 1 machine'). Why there is a desire to discuss them in the same breath is beyond me. Both can be described in a handful of written pages, eg., the tail end of the old chapter four of TTM and the later Appendix A "formal definitions" precisely describe a relational machine (virtual machine if you like). This machine is not temporal, ie., has no facility concerning time, no notion of state, eg., no variable pointers, no assignment. It is a purely algebraic machine. On that basis, LISP would appear to be sufficient to implement it. Whether people would find the use of such an implementation convenient is another question.
It is possible to ignore another kind of model, based on 'type theory' which hadn't become prominent when Codd wrote his first papers. As far as I know, the original Codd machines did not decide equality, implementers left that to machine bit comparisons. Whether a practical machine needs to implement a more abstract type theory is still up for grabs. D&D have pointed out that certain object notions provide leverage for this, at the cost of much greater complexity. I don't pretend to know much about type theory but I'm still pretty sure that D&D have done something the OO people have never done, attempted to make the a type machine's behaviour precise, by defining the concrete values that result. Received on Fri Apr 09 2010 - 15:47:57 CEST