Re: what are keys and surrogates?

On Jan 10, 6:13 pm, David BL <davi..._at_iinet.net.au> wrote:
> On Jan 10, 4:02 pm, Marshall <marshall.spi..._at_gmail.com> wrote:
> > On Jan 9, 9:07 pm, David BL <davi..._at_iinet.net.au> wrote:
> > > On Jan 10, 11:44 am, Marshall <marshall.spi..._at_gmail.com> wrote:
>
> > > Is "constructor" the same as what C. Date calls a "selector"?
>
> > Yes. Date calls it a selector, and the entire rest of the world
> > calls it a constructor. :-)
>
> I think selection (ie specification) of a value is a different concept
> to construction of an object (or variable, if you prefer). It seems
> that Date wants to emphasise the distinction.

Hrm hoom. Well, kinda, but that doesn't really match the way I use the terminology. Anyway I think we're clear here.

> > > How do operators fit into that picture - given that a type is
> > > conventionally a set together with the operators available on that
> > > set?
>
> > The picture includes functions. Functions have in and out
> > parameters. There are no methods.
>
> Have you considered the idea that a function maps an input tuple to an
> output tuple? So
>
> f x
>
> represents a tuple which is the application of function f to tuple x,
> and
>
> f (1,2)
>
> is seen as consistent with that notation where (1,2) is a constructor/
> selector for a tuple value.
>
> I have wondered whether this combined with some operators to provide
> direct support for tuple manipulation (such as flattening a tuple
> within a tuple) could form the basis for a hybrid language that
> encompasses relational, functional and imperative "computing
> models". Not my area of expertise though!

This is roughly what I'm currently pursuing: a unification of the relational operations with the functional ones. Under my thinking, function application is simply the natural join followed by a projection over the symmetric difference of the attributes. There is nothing particularly special about the case when one operand is a relation.

> > I think it would be neat if you could, for example, have
> > declarations like
>
> > +:(x:num, y:num -> z:num)
> > +:(x:int, y:int -> z:int)
>
> I see that as part and parcel of the important idea of compile time
> algorithm selection available through overloading on type.

Yes.

> It also reminds me of an interesting point. Consider that int64,
> int32, int16 are various rings for modulo arithmetic. Would you say
> that according to the concept of value-type inheritance espoused by
> Date, we would want int16 to be a subtype of int32 which is a subtype
> of int64?

I don't try to represent what Date's views are. I'm fairly familiar with them, but no expert.

> This is possible if for example int32 inherits the int64 +
> operator (which can yield an int64 result) as well as defining its own
> independent modulo 2^32 version of a + operator.

I think I would be more inclined to say that there is a type int<n> (with ring operators) and int32 = int<32> etc.

> ie the following two operators are distinct
>
> + : (x:int64, y:int64 -> z:int64)
> + : (x:int32, y:int32 -> z:int32)

Yes!

However, I think I would say instead:

  +% : (x:int, y:int, n:nat -> z:int) [z

is the function in question, and we can partially apply this function to the relation {(n=32)} or {(n=64)}, possibly at compile time, and end up with a binary operator that will feel very familiar to the C programmer.

> A function using the first + operator that accepts int64 will work
> correctly when passed int32 values - so it's reasonable to support
> implicit conversion of int32 values to int64 values.

I don't see it as a conversion in the usual sense.

  {x:int | -(2^31) <= x < 2^31}
    is a subset of
  {x:int | -(2^63) <= x < 2^63}

> > and have the system know from this that it can add any
> > two numbers, but also that it can (efficiently) add two
> > integers, and that when you add two integers you always
> > get an integer.
>
> I wonder how modulo arithmetic fits into that picture (where the +
> operators are logically distinct).

I thought we were just talking about modular arithmetic!

In my current view, there are three different manners of +:

+ addition defined over whatever subset of the computable

    numbers we are going to support, which cannot overflow,     but which can fail on resource exhaustion. +% modular addition, which is parameterized by the divisor,

    which may overflow (ie, exceed the divisor) but which will     not (under the popular divisors) fail on resource exhaustion. +. floating point addition, which approximates +, and which

    hardly ever overflows and never fails on resource exhaustion.

Presumably all are available to the programmer, and presumably he has some way, if he chooses, of specifying one of them to be written with the + sign.

Marshall Received on Fri Jan 11 2008 - 06:26:19 CET