Re: Homoiconic relational programming language

On Apr 8, 7:25 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:

>> 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.
>
> I disagree. It is an algebraic structuring that biases neither toward
> breadth nor toward depth.

That is part of why I said my answer was "partial": the difference really is quite difficult to put into words. I was describing my intuition as somebody who has to produce code in both paradigms. Algebraic and declarative are two other words for the relational mindset, yes.

I chose breadth-first because that's how I, and I think most relational, coders lay out their code. The idiot level for OO/ declarative is to go with the control flow, structure it irregularly with regard to the access depth, and so on. Within the RM the same thing is to start with one set of tuples/relation and then progressively lay out new layers outwards from it, using joins as a symbolic, set-level equivalent of good-old record pointers. The hallmark of that fu is copious one-sided outer joins branching out from a single base table (I just had to update some code like that).

But even what I think of as being proper style puts out all of the relations, their mutual dependencies, query constraints, and so on, more or less at the same level; there is no real nesting involved as there is with hierarchical program flow within a structured, procedural language. (And OO languages are even moreso than the older ones like Modula.) Plus, our common-day notion of recursion tends to be rather limited compared to what you can do within a Turing complete language: we don't really do ragged recursion over several datatypes, for example. Again, a purposeful choice, because that makes our optimizers much simpler and more effective for bulk operations; but it does limit DB's from doing certain things like the topologically oriented stuff I mentioned, or perhaps very complex and plastic data models, such as they use in CAD/CAM, bioinformatics, or linked data; there is nothing in the RM as such that would stop it, and I'm a staunch advocate of that sort of development, but in current relational data languages you can't really go there.

One telling sign in this regard is that our declarative paradigm hasn't really gone past finite FOPL at the standards level. Sure, we have special case solutions like Oracle's CONNECT BY clause, and the newer SQL's subquery factoring clause. They can more or less solve the classical BOM problem. But do they really do much else, so that we could e.g. support introspection and ragged recursion over multiple data types simultaneously, while keeping to the declarative roots of RM? Is there for example a sturdy implementation of a multiple table, parallel transitive closure operator anywhere, which meshes well with basic relational algebra? (Least of all a least-fixed-point operator which would be sorely needed for RDF/OWL-sorta work.) I don't think so, and that's pretty much the minimum of what they're doing with object frameworks right now -- even when doing it at the highest meta levels that their languages allow.

> > 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.
>
> What do you make of Date, Darwen and Lorentzos?

I have a problem with them and I haven't much read them, I have to grant. The former two, mostly, Lorentzos I don't seem to remember distinctly. I've grown into the relational camp, even "ideologically speaking" (e.g. the RDF folks have long since stopped liking me much because I now and again tell them, in their own terms, that they're dealing us EAV, and that that's been proven bad many times over), but still Date and Darwen do not seem to be contributing much in my judgment. Except perhaps demagoguery. Perhaps the best example of this to me is how they handle objects within the relational model: they approve of them, but never really seem to square away the difference between flat and rich relations at the theoretical/conceptual level.

Before you jump in, let me outline my idea about how it should be done as well; no point in judging without counterpoint, you know... To me the RM is about axiomatic semantics, as opposed to intuitive ones (the latter have their value, they belong to the third level of the ANSI model, the conceptual one), so you have to be able to perform as a mathematician when developing the theory further. That means speaking about the theory purely based on the axioms/properties it follows. And so complex objects could in theory be admitted into the model...when they *behave* as though they were atomic values when referred to as such. At that level of pointlike members of sets/unique names, objects are pretty cool as part of the model. But then on information principle grounds they should also be broken down into atomic stuff elsewhere in the database, so that we can use relational operators to drill into their real guts. No nested stuff, a minimum amount of type specific operators, and so on. Date and Darwen *never* spell that out loud, which in my mind means they're betraying basic information modeling principles in service of good publicity.

Also, they *never* stop to consider the fact that relational algebra might not be good enough for certain data handling tasks. Do pardon my language, but they seem like blind believers to me, and as such not very useful in developing RM further. Call me a passionate heretic if you will, then, but I'd rather get my information somewhere else. *Because* I care about sound principles.

--
Sampo