Re: What databases have taught me

Marshall wrote:
> Well, some. Lots of thinking. A trial syntax. Some ambitious
> ideas. There is an interpreter for it, but it's never fully functional,
> as I keep changing my mind about important design decisions.
> For example, a few months ago I ripped out default arguments
> when I realized they broke associativity of natural join. :-(

I have never been a fan of default arguments, since I first encountered them in Ada. A function that needs default arguments is a function that's trying to do too much, it seems to me.

> Sadly, I'm not very good with formal methods yet, so I don't
> have an operational semantics. But it's something I want to do.
>

"Pshaw" says I to operational semantics ;) Check out http://www.cis.ksu.edu/~schmidt/text/densem.html for free PDF or Postscript of David Schmidt's most excellent "Denotational Semantics: A Methodology for Language Development". A very good (and when I wanted to buy it in 1987, very *expensive*) book on denotational semantics. Lloyd Allison's introductory book, "A Practical Introduction to Denotational Semantics" (Cambridge Computer Science Texts No. 23) is a short, quick and decent introduction which might get you going quicker, but isn't available on line (it's quite cheap though - £15 currently). Lloyd Allison has a website at http://www.csse.monash.edu.au/~lloyd, and his list of programming languages contains the excellent joke :

"The last good thing written in C was Franz Schubert's Ninth Symphony."

• Gregory V. Wilson

> Its primitive operators are those of the Tropaskho algebra:
> natural join and inner union. The language is pretty much
> just: those operators, scope and name binding, the type
> system,

Just ?! Languages are invented just to play with type systems, never mind anything else :)

> the imperative commands,

Oh, boo ...

> and a few bits of
> miscellany, such as aggregates/group-by. High up on
> the wanted-feature list is constraints and updatable views.
> But the precise semantics of view updatability remain
> elusive.
>

Well, you've got to start *somewhere*. Pick the low-hanging fruit and make sure you've designed the spec in such a way that adding the fun stuff is easier later (even if someone else gets to do it). Design the semantics first - an interpreter will surely follow :) Received on Sun Jun 25 2006 - 03:39:24 CEST