Re: relations aren't types?

> I don't see how you can write functions which operate on dates without
> knowing something about the structure of the date. How would you write
> "year" without being able to extract the year from a date?

I hate to admit it, but Bob's right. ;)

> Unfortunately I couldn't find a good link comparing the type system of
> Haskell to other languages. But here's about Haskell in general:
> http://www.haskell.org/aboutHaskell.html

Thanks for the link, it looks like I have quite a bit of reading to do.

> I'm not sure how this disagrees with what I said above. All this stuff
> has to be implemented in SOME language -- if your database language is
> powerful enough to describe all the datastructures users might come up
> with, it can also describe the datastructures which the database is
> founded on.

At the end of the day, all we really want is a good language that allows us to model all the data we need, and doesn't tie our hands like SQL. We have found that in TTM, with a minimum of data structures. All we really need is relation, tuple, list, and scalar. We are looking at an operator type as well, but so far we haven't decided what that would look like. I am definitely going to research Haskell, and see if some of the ideas will apply. From the introduction, it looks like a perfect match (relational and functional) but we'll have to see.

> I think most languages have too many kinds of syntax: there are usually
> several different iteration syntaxes (which can be replaced by recursion
> or higher-order functions),

We have four different types of iteration constructs, but they all compile down to a while loop internally. Having used a language with only one iteration construct (T-SQL) I have to say I *much* prefer having multiple looping constructs. Different scenarios require different types of loops. To fit all logic into one requires excessive footwork.

> there are blocks versus expressions (when everything can be an
> expression),

Not sure I agree with this. At some point I have to change the state of the database, or my language is useless.

> I'm not part of the database community but the only innovations I hear
> coming from that direction are backwards (like XML, OODB, "Persistence"
> or whatever that new Java object storage is called) or academic
> vaporware like TTM.

It's not just vaporware, there is at least one commercial implementation. Received on Tue Jan 13 2004 - 06:51:49 CET