Re: Object-relational impedence

On Mar 6, 9:27 am, S Perryman <q..._at_q.com> wrote:
> Marshall wrote:
>
> > Many good things can be said of this pattern, but it is not set-oriented.
> > I am not familiar enough with OCaml to say much. But
> > if we were talking SML, (a language I have the utmost
> > respect for) I would still not consider it set-oriented.
> > map(), filter(), fold(), while providing collection-oriented
> > interfaces, are typically not primitive in the language.
>
> OK.
> You regard "X-oriented" as something for which the facilities to support
> X are provided at a fundamental level (like arithmetic ops, CAR/CDR in
> Lisp etc) and not built (by whoever) from the fundamental constructs of
> a prog lang.
>
> Fair enough.

Right. If we consider *potential* built constructs, and we are speaking of general purpose programming languages, then right away all languages collapse into a single category.

We might make some allowances for languages whose standard library contains specific constructs, however. We might reasonably classify some functional languages that make extensive use of map, filter, and fold as being at least modestly list-oriented, despite the fact that their list constructs are really recursively defined union types. But it's probably better to consider the recursively defined type together with the higher-order function constructs as being the axiomatic signature of such languages.

Another important reason to consider the fundamental constructs of a PL is so that we can treat the PL as an axiomatic system. To me, the most interesting thing one can do with code is *reason* about it. This is why type systems are interesting (and "dynamically typed" languages not so much.) It's also part of why the relational model is so interesting. And it's why OOPLs don't hold my interest so much any more; their axioms are complicated and often weak.

> M>Why are you bringing up functional programming when
> M>talking about OOPLs?
>
> >>Because FP has :
> >>- been able to support OO quite easily
> >>- has an interesting execution infrastructure that IMHO makes it a
> >> good candidate for supporting the Relational paradigm
> > Hrmmm, well, I have to admit you make a good argument here.
> > (Although you must grant me that, we people speak of OOPLs,
> > they are not usually thinking CLOS!)
>
> I would not call it an "argument" as such.
> More thinking out loud about candidate technologies for resolving
> the impedence problem (conceptually and performance-wise) .

By all means, please continue to think out loud. You do it well.

> > But I am, rather, speaking of what languages' axiomatic natures are.
> > I could, in fact, write a Relation class in Java, and provide set-
> > oriented
> > methods for it, and a whole host of relational goodness. But that
> > wouldn't make Java a relational language per se.
> > Virtually no languages have primitive support for anything like a
> > collection. SQL and SETL and a few others; that's it. There are
> > some languages that were designed from the start with *list*
> > processing in mind: lisp (and I should probably also mention the
> > APL family here.) There are some *very* interesting things
> > in there, but not things I would say could be strictly described
> > as set-oriented.
>
> I take a slightly different view in that I obviously have the need
> for various collection types, and support for a Relational "calculus"
> to use on those collections. I also need support for collections of
> ADTs in particular.

The collections question is quite interesting: Lists, maps, bags, sets, tables, trees. It is apparent after only a modest amount of study that maps, sets, and tables are thoroughly and beautifully handled with relations. It took me a lot longer but I've reached the conclusion that lists fall in to the same category.

Trees no longer seem like a single category to me: there are what I call "statically structured" trees, for example Customers/ Invoices/InvoiceLineItems, and "dynamically structured" trees, such as a parse tree. Statically structured trees are are a particular strong point for SQL and also a strong point for the RM. Dynamically structured trees *can be* handled with the RM but I don't think it does as good a job as is done in, say, FP languages with union types and structural recursion. I conjecture that it may be possible to develop best practices and/or tiny extensions to the RM such that it does as good a job, but currently I'm leaning in the direction of thinking this will not be possible. I'm not completely thrilled with structural recursion, but I have yet to see anything better.

Bags I have not looked at in any detail. They are certainly the least important of the lot, however.

> If possible I would like the prog lang user to be able to construct
> specific collections such as sets etc, and for the prog lang env to be
> within reasonable performance of something that is designed for the
> support of some one specific aspect (as Lisp is for lists etc) .
>
> I think that FP is the paradigm that could possibly do this.

An important aspect of the performance requirement is physical independence, something that is largely ignored in PL theory, sadly.

FP is an important area for study, no doubt.

If we look at the mathematical universe, we usually encounter an extensional viewpoint. And if something is expressed intensionally, or algorithmically, mathematicians are free to immediately think of its extension, because they do not have to limit themselves to what is computable.

On the other hand, if we look at the computable universe, we see more often the intensional viewpoint. And we are not free to immediately shift into extensional mode, because of the possibly-infinite, almost-certainly-prohibitive cost of doing so.

The RM gives the best handle on the computably extensional viewpoint I have encountered. FP gives the best handle on the intensional viewpoint.

There's more to this line of thought, but it's lunchtime!

Marshall Received on Thu Mar 06 2008 - 21:37:06 CET