Re: relations aren't types?

John Jacob <jingleheimerschmitt_at_hotmail.com> schrieb:
> I think this is the real power of the type system in TTM. I can
> expose both in a single type. I can treat a scalar value as a whole
> by invoking operators that take arguments of that type, or I can
> access the components of some specific representation of the type and
> manipulate those. I think that most type systems have a severe
> short-coming here because they equate the physical representation of a
> given value with the logical representation.

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'm convinced by experience with, i.e. Haskell which certainly seems to
>> be at the cutting edge of usable type systems. I haven't read TTM (yet)
>> though.
>
> Do you have a good link for an overview of Haskell?

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

>> While a bit of syntactic sugar around that would be nice, I don't think
>> it's crucial -- and the point is that you *could* have defined all these
>> types yourself without relying on builtin syntax for relations, if
>> efficiency weren't important.
>
> I'm still not sure I agree, there is so much that a database language
> compiler must take care of. It's not just the declaration of the
> types, it's the inference of the types through relational expressions.
> There is also functional dependency inference, and constraint
> inference.

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.

>> I'm a big fan of languages like lisp where EVERYTHING is either a macro
>> or a function expression, where there's no statements or blocks or
>> anything, so that's my bias.
>
> I'm exactly the opposite. I prefer a language where everything is
> plain as day and in your face. I would like to see an almost english
> formulation, (without noise-words like SQL, of course) but as readable
> as possible. For example, I prefer the syntax of Pascal to that of C.
> I think that macros and cryptic symbols obscure the meaning of the
> program, increase the learning curve for the language, and seriously
> hamper maintainability of the code.

We have the same goals: everything is in your face, language is easy to learn, code is maintainable, and C sucks -- just different opinions about what furthers those goals.

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), there are various type declaration syntaxes for records, arrays, etc. (which can be done at least more regularly), there are blocks versus expressions (when everything can be an expression), etc. If you know Forth that would be the ideal where everything is a word, but for human-readability I think a *bit* more structure is nice.

> If I'm understanding you correctly, you are proposing that a language
> like Haskell could and should be used as a database language. A
> functional relational language, right? I think this is an interesting
> possibility, and I wonder, have you taken any steps in this direction?

Well, Prolog is a functional-relational language (sort of) and has been around a long time.

I don't think the idea is controversial since for everything but updates you're going to be building new relations out of base ones in a declarative way, and this is precisely the kind of thing functional languages are good at. Functional languages also have more experience in logically sound type systems and type inference.

I haven't done anything in that direction nor have I heard of anything. 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. I'd love to build on the ideas in TTM (which I've heard about indirectly) to create the real relational database everybody wants, but I'm not nearly capable yet. Maybe for a master's project someday. Received on Mon Jan 12 2004 - 08:39:08 CET