Re: relations aren't types?

> This is where I think we're talking at cross purposes. A type doesn't
> have a "representation", at least as far as type theory is concerned --
> it describes a set of values (sometimes in terms of other sets). How
> it's represented depends on the compiler, though you might give the
> compiler hints.

I believe you are describing the physical representation here, which is necessarily hidden in TTM. The possible logical representations of a given value are exposed in the language in terms of other types. For relation and tuple values, this representation corresponds to the logical structure of the values. For scalar values, these representations are hidden, and only accessible through accessors. I don't know how this disconnect would be represented in type theory, but I do think it's a critical part of TTM.

> So you give an example of a date type which has a record representation
> and a string representation -- but "the set of records like this" and
> "the set of strings like that" are DIFFERENT TYPES, and obviously the
> same operations won't work on them since the same operations don't work
> on strings and records.
>
> But here's where we get into abstract datatypes -- if a type gives you
> no interface to it's values other than functions it exports, THEN you
> might be able to use different "concrete types" in place of that
> abstract type and the code is the same.
>
> But this "abstractness" is a property of the interface. If I let you use
> my dates as records, then they're not abstract, but if I don't, then
> they are. That doesn't depend on the type of the values themselves --
> they might still be records even if I don't let you use them as such.

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'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?

> Well, I think this doesn't imply syntax but just appropriate builtin
> constructors: i.e.
> type my_table = Relation RTuple {name: String, number: Int} [Constraint
> ...]

I know this is just example syntax, but I have to point out that you are describing a variable here, not a type. The syntactic extension must therefore be made to the variable declaration statement, not the type definition. I don't know whether this could still be done with appropriate builtin constructors.

> 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. The relational operators are such an intrinsic part of the model, it would be a major undertaking just to demonstrate that it was possible.

> And relational expressions should be just functions:
> (join foo bar) etc.

Agreed, but we have quite a few of them that we would like to be built-in just like + and -. We don't want to, for example, have to say
  Project(A, 'ID;Name');
We would prefer
  A over { ID, Name };

> 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. I would much rather see a little extra syntax, especially where the user is concerned. I don't think this goal is at odds with having a good, orthogonal language either. The important part is that the language have relatively few, well-defined, and simple concepts, and be built completely from those concepts. I believe strongly that the language described in TTM satisfies this criteria.

I also have some general concerns about functional languages like LISP. This is probably not the forum for a discussion of the relative merits of functional versus imperative languages, but I'm not convinced that a functional language offers anything over the expressive subset of a good imperative language. I certainly think that imperative languages are much more intuitive than functional ones, at least for me. I don't think functionally, I think imperatively. Maybe this is a handicap I need to overcome, but if so, I'm certainly not alone in suffering it.

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?  Do you know of any functional relational language implementations? Received on Mon Jan 12 2004 - 07:14:39 CET