Re: what are keys and surrogates?

On Jan 10, 11:44 am, Marshall <marshall.spi..._at_gmail.com> wrote:
> On Jan 9, 5:26 pm, David BL <davi..._at_iinet.net.au> wrote:
>
> > > I'd just say, a la SML:
>
> > > product(sum(5, 6), x)
>
> > So is the name of a relation part of its value?
>
> No. The "product" and "sum" above are what are usually called
> "constructors." The above is a value. You can put it in a relation
> if you want. (Probably I introduced the confusion by talking about
> union types immediately after talking about RVAs.)

Is "constructor" the same as what C. Date calls a "selector"?

> > If "relational" encompasses too wide a spectrum then the word starts
> > to become rather meaningless. It's not meant to have any bearing on
> > how one solves problems - I'm not suggesting that RVAs are evil in any
> > sense!
>
> Okay. But let me be explicit: in my mind the "ideal" programming
> language encompasses different "pure" computing models into
> a single hybrid computing model. That model will necessarily
> include relations, (because they are so awesome) and it will
> also necessarily include other things, such as first class functions,
> because they too are awesome.

I completely agree.

> > > > How does the typing system work with such an approach? ie how do you
> > > > constrain the allowed RVAs?
>
> > > What's wrong with the usual way?
>
> > I don't know what the usual way is. There are different ways of
> > defining relation types. For example one can define a relation type
> > that encompasses all possible relations, or one can parameterise on
> > the types of the attributes, or one can parameterise on both the names
> > and the type of the attributes. In addition one could allow the
> > system to define distinct types even though they have the same names
> > and type of attributes. This seems to relate to Jim's recent post on
> > POOD.
>
> Well, my own thoughts in this area are evolving and may
> sound pretty weird at this point. Roughly: there are two "kinds"
> of values: relations and atoms. The type of a relation is
> exclusively the set of its attribute names. Atoms don't have
> types, however we may specify a set of atoms in such a
> way as looks very much like what is usually called a type.
> (Thus: we have the set of natural numbers, and we have
> the set of integers, and N is a subset of Z. And we can
> tell of an atom whether it belong to N, etc.) In addition
> we have constraints, and the constraint language is
> Turing complete (and hence not decidable.) We can
> specify a constraint on a variable, in which case it is
> a runtime construct, or we may specify a constraint
> on immutable constructs, in which case they should
> be checked at compile time. Under this scheme much
> of the machinery usually associated with types gets
> taken over by constraints.

How do operators fit into that picture - given that a type is conventionally a set together with the operators available on that set?

> This is just my own particular way of thinking; it doesn't
> represent anything more than that.
>
> > > > Would there be some concept of
> > > > inheritance for relation types (by analogy to an OO implementation of
> > > > an AST that uses a Node base class)?
>
> > > I'm inclined to say NOOOOOOO!!!!!</vader>
>
> > I wonder then how all the relevant constraints would be specified.
>
> Given a Turing complete constraint language, any constraint
> that can be computed can be expressed. I don't think you
> can do any better than that. :-) Of course, this approach brings
> its own issues ...

Like needing Ctrl+C to abort the compiler! Received on Thu Jan 10 2008 - 06:07:58 CET