 | |
Homoiconic relational programming language
comp.databases.theory comp.databases.theory
 |
| | Thread Tools | Display Modes |
#11
 
| |||
| |||
|
Re: Homoiconic relational programming language -
04-09-2010
, 09:47 AM
|
On Mar 8, 1:14 pm, Nilone <rea... (AT) gmail (DOT) 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). -- |
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.
#12
| |||
| |||
|
|
Sampo Syreeni wrote: On Mar 8, 1:14 pm, Nilone <rea... (AT) gmail (DOT) com> wrote: ... The motive for the comparison is a good one because without it we have no context to distinguish different models. ... |
follow.
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.