> With respect, I believe that is at least partly because you have no
> experience with a proper functional implementation of the relational
> algebra.  (Few people have.)

No respect earned - I'm a total pleb when it comes to databases.

> Relational programming is another paradigm
> like structured programming, object-oriented programming, and logic
> programming, all of which Scheme can handle and handle well.

It's entirely possible that the original idea was nice to use.

> Relational programming in SQL, on the other hand, is like functional or
> OO programming in C: it is technically possible, but you keep running up
> against roadblocks placed for historical reasons that are no longer
> relevant.   SQL is not only both too simple and too complex to do the
> job, it is full of idiotic limitations (examples on request).

That sounds like a good relational programming language is made out of
simple, orthogonal, composable building blocks and SQL is not.

> Unfortunately, it is all we have.  Still, translating high-level
> languages to C has its good points, and so does translating high-level
> relational algebra to SQL as needed.

How big/complex is a relational algebra -> SQL translator, and how much
overhead does it impose on typical workloads? Is Dee being used for
applications?

> Following in the footsteps of Dee (a Python library for relational
> algebra), I think a good integration into Scheme is possible.  It will
> not be an ORM, because mappings between paradigms always suck.

Yes - object-relational mapping is the Vietnam of computer science, etc.

> But Scheme is inherently a multiparadigm language.

I've grown to like Scheme's approach of taking the essentials from each
paradigm and making it all opt-in rather than opt-out.