Rel: an open source implementation of Date & Darwen's Tutorial D

More from Slashdot, which today points to an article on Rel, Dave Voorhis' open source implementation of Tutorial D (see Chris Date and Hugh Darwen's The Third Manifesto for a discussion of the rationale behind this language).

Voorhis explains his motives for creating the implementation in an article on the (currently somewhat sparse) Rel Wiki.

Discussions of possible replacements of, or improvements on, SQL usually end up being all about the powerful institutional/human factors (or "network effects") that will impede acceptance of any new solution. Refreshingly, Voorhis is going ahead and building one anyway, without waiting for approval from the masses. It might catch on, or it might not; at least someone's giving it a go.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

An implementation of Date & Darwen's Tutorial D

The company Alphora has a product Dataphor which is a fairly mature (not open source) implementation of Tutorial D

Now with added SQL Nulls!

I did have a look at Dataphor a while back. One impressive feature was that it converted Tutorial D expressions as far as possible into SQL statements to be executed by the underlying DBMS product (which could be Oracle, SQL Server or whatever), thus taking advantages of whatever optimisations that product employed.

I understand Rel is built on top of Sleepycat's Berkeley DB, and is fairly unoptimised at the moment.


One problem I have with this is that it doesn't address the issue of accessing the database from other languages. Right now most SQL is generated dynamically from within another language; there's various ways to cope with this, but it feels rather crude anyway.

I feel like it would be advantageous to think less in terms of ASCII syntax, and more in terms of a more clearly structured syntax for expressing abstract queries. I suppose this could be XML, because everything these days is XML, but maybe S-Expressions or something else would also work. Simplicity of *syntax* seems much more important than expressiveness.

I also don't get why they'd get rid of NULLs; sentinals are important to all my programming, database and otherwise. To require ad hoc sentinals will only lead to more sentinal-related bugs, and make it harder to understand the data. I don't think they are sufficiently concerned with real programming practices.

I'm much, much more interested in ways to make relational databases easier to refactor. But I don't see any movement in that direction with this.

their suggestion for NULLs

is that any column that has nulls should be moved into a child table (maybe a one-column table)

The null-rows become non-rows (they have no entry) in this new table.

Logically, if a NULL is 'missing information', then in this solution, it actually IS 'missing information'.

The result (AFAICT) was to make the logic of some statements a lot simpler - the usual 'is not null' clauses disappear (but the joins are more complex ...)


And that's why I don't take them seriously. Converting a table with N columns into N-1 tables with two columns is not my idea of progress.

It's as if someone proposed to get rid of the "clear" bit in GIFs, because after all, any non-rectangular image composed of pixels can be decomposed into a lot of little rectangular images, and image-processing code would be cleaner if we didn't have to special-case the clear bit...

(Then again, these days we use the alpha channel for image transparency. I wonder if there's an analogy for relational databases?)


"Converting a table with N columns into N-1 tables with two columns is not my idea of progress."

This is not the intent, nor the general outcome. The ideas are best explained in "The Third Manifesto" by Darwin and Date.

The issue is only that there is nothing in the relational model that prevents objects being stored in fields, not that they must be.

humph squared

when was the last time GIF had pretensions of ensuring data integrity in a general purpose database system?

I'd love it if databases were easily programmed, speaking as one who's had his enough Pro*c coredumps for a lifetime. but why should a technology aimed at a completely different audience & purpose be changed to make my life easier?

Relational DBs were not meant for programmers. Ever.

Language Neutral and Refactoring

Do we not already have the language neutral aspect - either relational algebra or (the equivalent) relational calculus? However, once you want to talk to Oracle, SQL Server, DB2 and the like SQL is about all the vendors will give you.

BTW, what do you mean by "refactor" a database? Could you give a concrete example please?

compare/contrast with HaskellDB?

Is this different from or better than HaskellDB?

I've been calling HaskellDB a database unwrapper because it exposes the set theory rather than the SQL.

Is that also the goal of Tutorial D?

Shae Erisson -

the goal of Tutorial D

was to present a relational language


do some kind of reconciliation between relational and OO databases.

It's been a while since I read it but they propose that OBJECTS should be mapped to COLUMNS, not to ROWS.

They claim that it is columns (data types) that have operations defined on them, not rows, and that's the logical mapping - defining operations on rows (what most "oo mappings" actually do) makes no sense in relational terms.

(this is from memory, correct me if I'm wrong) ...

I've forgotten what their suggestion was for replacing all the current code that defines "operations on rows" (AKA objects that pretend a row is the correct type to define operations upon).

actually just remembered as I write ... one suggestion was to put more emphasis on integrity rules so code can be moved out of objects and into the databaase.

Pretty much.

I snagged a copy of their book "The Third Manifesto..." a while back. I was more interested in getting at the theoretical underpinnings of the "Relational Model", which the book attempts to explain, partially by answering the question of how to "extend" object-oriented ideas into databases.

The short answer to your question is, "Most definitely, a big yes."

They think that SQL, while allowing a programmer to try to conform to the relational model, does a lot to mess it up too, made worse by the typical implementations of SQL found in commerical systems. Tutorial D was their attempt at trying to fix that by not burdening themselves with compatibility with SQL.

Now, the thing is, while they are smart guys, and mathematical purity of the relational model are all to be appreciated, having studied programming language design myself(which is why I hang out here too much :) ), I think they are not sufficiently aware of the research in programming languages, and so while Tutorial D is faithful to their goals, seems a bit off at times(at least to me), especially since they talking about "typing systems", and it seems that there is a lot of work they are unaware of(I know because I am aware that I am unaware and trying to study it...).

As to other issues people bring up. They designed Tutorial D to be complete, so the issue of accessing a DB from another language is ignored. As to other goals people have like persistance of "objects" and/or serialization was not something they were concerned with either.

Perhaps the biggest issue that they feel DB's fail on is support of "updateable views", integrity constraint enforcement, support of user defined data types, and proper support of "keys". These are primary causes, whereas issues like NULL's, hierarchial databases, "too many tables/normalization is bad/joins are bad..." are the result of DB's not implementing these things properly, and that most programmers are not taught to understand the model.

Of course, I've wondered about design of a better language for DB stuff since I started messing with them, and their ideas have the ring of truth and the support of mathematics, its mostly lacking proper packaging in a programming language.

One of the more amusing sidenotes about trying to replace SQL are about performance/scalability in "commercial" db's. My experience is that most people wanting a DB, need it for like 10 people to hit it a dozen times a day. Now I realize there are _other_ situations out there, but I think making databases usable for "common people" in a theoretically appropriate way is the best way to empower users to write their own "code" to get work done. Of course, I'm not fond of the arrogance some of my peers have towards "common users", but that's a different issue for a different time...