Re: no names allowed, we serve types only

#31

On Feb 17, 10:08*pm, Keith H Duggar <dug... (AT) alum (DOT) mit.edu> wrote:

Quote:

On Feb 17, 7:21 pm, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

On Feb 17, 3:46 pm, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:
The thread started as Keith's attempt to demote attribute names in
favor of types,

Eliminate not just demote.

and was vehemently objected to. From my angle (that
would be relational lattice:-) Relational Model is a theory of
Relations with Named Attributes. It is difficult to see unnamed
perspective (with positional attributes) as contender anymore. This is
especially evident through the prism of set intersection join (aka
composition) operation...

Except that I'm not proposing "positional attributes" so I fail
to see the relevance of your point?

I was addressing Named perspective vs. Positional perspective p.31-33
in the Alice book.

Quote:

First, I'm asking a simple
question: suppose we have already have unique types for every
header then what theoretical capability do the names add? (Bob
argues that they are necessary for "controlling" natural join.
I disagree that they are /necessary/ for this; but my complete
response to that will have to wait a few days.)

And, adding to Bob's point, there are many more [non-classic]
relational operators that depend on the attribute naming.

The issue is more complex, though. The algebra with unnamed attributes
(that is Algebra of Binary Relations) is arguably much more
established construction in math. The parallels between it and
Relational Algebra (in the lattice form) are puzzling. In Algebra of
Binary Relations they have two versions of each operator: logical and
relative. Composition is relative analog of conjunction, converse is
relative analog of negation and so on. In Relational lattice there are
two versions of conjunction, two versions of negation and so on. It is
natural to extend your question and wonder if types are of any use for
Algebra of Binary Relations?

#32

Snipped

Quote:

The thread started as Keith's attempt to demote attribute names in
favor of types, and was vehemently objected to. From my angle (that
would be relational lattice:-) Relational Model is a theory of
Relations with Named Attributes. It is difficult to see unnamed
perspective (with positional attributes) as contender anymore.
Who said that an un-named attribute theory of relations imposes a

position on attributes.

Quote:

This is
especially evident through the prism of set intersection join (aka
composition) operation...
How?

#33

On Feb 18, 7:44*pm, David BL <davi... (AT) iinet (DOT) net.au> wrote:

Quote:

On Feb 15, 3:01 pm, Keith H Duggar <dug... (AT) alum (DOT) mit.edu> wrote:

Of course if you are dealing with crippled domain support then names
are essential. But envision a system with rich type support. I'm
asking
if, in that world, we even need to bother with attribute names at all?

I think a rich type system is desirable. *I suggest there should be as
many types as necessary according to exactly where it is considered
useful to test for equality. *No more and no less.

For example, it isn't particularly useful to compare a person's weight
with a person's height, so it would be reasonable to have specialised
types like MASS_IN_KG and LENGTH_IN_METRES. *These are like copies of
NUMBER, but the idea here would be for them to really be distinct
types (i.e. no implicit conversions). *I think they should be strict
subtypes of NUMBER. * They would inherit arithmetic operators from
NUMBER, such as the signature

* * NUMBER *<-- NUMBER + NUMBER

which appears to defeat the purpose somewhat. *E.g. *it is possible to
add a MASS_IN_KG to a LENGTH_IN_METRES. *However this is safe because
it returns NUMBER which cannot be implicit downcast to a more
specialised type.

Ideally the type system would add all the appropriate specialisations
of the operators (which for example are covariant on return type).
E.g. * a plus operator that allows two masses to be added to give a
mass. *Strictly speaking this is a distinct operator to the plus
operator inherited from NUMBER, so operator overloading would be
necessary to make this practical.

A curiosity is that the super-type NUMBER doesn't play the role of a
scalar (where by scalar I mean a dimensionless quantity). *For
example, if one tried to define a scalar multiplication like this

* * MASS_IN_KG *<-- NUMBER * MASS_IN_KG

one would find that any specialisation of NUMBER can serve as the
scalar. * Instead one seems to need to define a common sub-type of all
the specialisations of NUMBER, to serve the role of a dimensionless
number in the type system.

Types are entirely misguided approach to physical units. Much more
elegant way is to operate units as if they are numbers, for example
the expression 10 * kg / (10 * sec^2) is multiplication/division of 4
number-like entities. One can use the laws of associativity/
commutativity and reduce it to 1 * kg/sec^2.

#34

On Feb 19, 1:33 pm, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

Quote:

Types are entirely misguided approach to physical units. Much more
elegant way is to operate units as if they are numbers, for example
the expression 10 * kg / (10 * sec^2) is multiplication/division of 4
number-like entities. One can use the laws of associativity/
commutativity and reduce it to 1 * kg/sec^2.

Interesting and that does look elegant. Are you suggesting the
computer manipulates these symbolic expressions so as to rearrange
them into a canonical form

value * unit

(i.e. units are moved to the right hand side of a multiplicative
expression).

How does validation fit in, if it's not part of the type system? I'm
guessing it's based on unification of symbolic expressions. Is that
right?

I believe the design/implementation of a DBMS is normally broken up
into rather distinct "layers", one of which deals with domain support
(both built-in and user-defined types) and another that deals with the
RM itself and treats domains as generic types.

I'm struggling to understand how a domain datatype could support units
in the way you describe without the generic RM layer ending up
physically recording a unit against every recorded numerical value.
Obviously that's not practical.

If a numerical data type supports units then it must record the unit
as part of an encoded value. If it doesn't then the unit must be
associated statically with the data type itself, contrary to your
claim that types are a misguided approach to physical units. Is it
possible to evade that conundrum?

#35

On Feb 19, 12:35*am, David BL <davi... (AT) iinet (DOT) net.au> wrote:

Quote:

On Feb 19, 1:33 pm, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

Types are entirely misguided approach to physical units. Much more
elegant way is to operate units as if they are numbers, for example
the expression 10 * kg / (10 * sec^2) is multiplication/division of 4
number-like entities. One can use the laws of associativity/
commutativity and reduce it to 1 * kg/sec^2.

Interesting and that does look elegant. *Are you suggesting the
computer manipulates these symbolic expressions so as to rearrange
them into a canonical form

* *value * unit

(i.e. units are moved to the right hand side of a multiplicative
expression).

How does validation fit in, if it's not part of the type system? *I'm
guessing it's based on unification of symbolic expressions. * Is that
right?

I believe the design/implementation of a DBMS is normally broken up
into rather distinct "layers", one of which deals with domain support
(both built-in and user-defined types) and another that deals with the
RM itself and treats domains as generic types.

I'm struggling to understand how a domain datatype could support units
in the way you describe without the generic RM layer ending up
physically recording a unit against every recorded numerical value.
Obviously that's not practical.

If a numerical data type supports units then it must record the unit
as part of an encoded value. *If it doesn't then the unit must be
associated statically with the data type itself, contrary to your
claim that types are a misguided approach to physical units. *Is it
possible to evade that conundrum?

My message was an echo of 4 year old discussion
http://groups.google.com/group/comp....e7dbff4b004268

#36

On Feb 19, 2:35*am, David BL <davi... (AT) iinet (DOT) net.au> wrote:

Quote:

On Feb 19, 1:33 pm, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

Types are entirely misguided approach to physical units. Much more
elegant way is to operate units as if they are numbers, for example
the expression 10 * kg / (10 * sec^2) is multiplication/division of 4
number-like entities. One can use the laws of associativity/
commutativity and reduce it to 1 * kg/sec^2.

Interesting and that does look elegant. *Are you suggesting the
computer manipulates these symbolic expressions so as to rearrange
them into a canonical form

* *value * unit

(i.e. units are moved to the right hand side of a multiplicative
expression).

How does validation fit in, if it's not part of the type system? *I'm
guessing it's based on unification of symbolic expressions. * Is that
right?

I believe the design/implementation of a DBMS is normally broken up
into rather distinct "layers", one of which deals with domain support
(both built-in and user-defined types) and another that deals with the
RM itself and treats domains as generic types.

I'm struggling to understand how a domain datatype could support units
in the way you describe without the generic RM layer ending up
physically recording a unit against every recorded numerical value.
Obviously that's not practical.

If a numerical data type supports units then it must record the unit
as part of an encoded value. *If it doesn't then the unit must be
associated statically with the data type itself, contrary to your
claim that types are a misguided approach to physical units. *Is it
possible to evade that conundrum?

Looks like MS has recently worked this into their F# language, by
allowing units as parameterizations of types.

Interesting series of blogs that delve into it in great depth:
http://blogs.msdn.com/andrewkennedy/...ing-units.aspx

#37

On Feb 20, 10:40 am, David BL <davi... (AT) iinet (DOT) net.au> wrote:

Quote:

I agree this provides some motivation, but it doesn't seem sufficient
justification to "conflate" concerns (as Bob says). The crucial point
is this: The attribute domains are part of the relation-type, whereas
the attribute names are part of the relation-value. What happens with
your suggestion?

It's very important to keep a clear separation between a value and its
declared type, in order to understand equality. Your suggestion ends
up conflating relation-type and relation-value.

How do you support sub-typing of relation-types according to sub-
typing of the attribute domains, and still allow for addressing the
attributes by type name? It seems you are forced to support multiple
typenames for an attribute. E.g. a relation has an attribute
containing circles and you must allow it to be addressed using either
circle or ellipse.

Oops, I got confused saying "your suggestion". Of course I mean
"Keith's suggestion"

#38

On Feb 21, 6:05 am, Jan Hidders <hidd... (AT) gmail (DOT) com> wrote:

Quote:

Btw. was the typing rule for equality already discussed? That's not as
straightforward as some might think. One proposal could be that t1 =
t2 is allowed if t1 and t2 have at least one common supertype. Or
should that be subtype? Or both? :-) The right answer depends on
several things such as the chosen semantics of your types; two types
would be semantically incomparable if the intersection of their
semantics is empty. I can easily imagine that the schema designer
should be able to indicate explicitly that two types are incomparable,
even though they would be semantically comparable.

Unless I've lost track, it was only briefly discussed

http://groups.google.com/group/comp....584d495812974f

in the context of operator specifications in general. So a type
system could allow fine grained control over the signatures that
are implicity/explicity allowed with/without coersion. In the
example below I'm going to continue using "copy" to denote the
declaration of a "strong" type alias ie it creates a distinct
type not just another name for same type. So let's suppose we
define X and Y coordinates type as copies of an Integer type

copy Integer X
copy Integer Y

and that by default the type system does not supply implicit
coersion nor the multi-sorted equality operators. Then we would
explicity add those multi-sorted signatures

= : X, Y -> bool
= : Y, X -> bool

to the type system. This would allow X and Y equality comparison.
Now suppose elsewhere we have defined a part count

copy Integer PartCount

but do not add the multi-sorted (with X and Y) equality operators.
Then PartCount will not by default be equality comparable to X and
Y. This allows one to control the semantics.

One can also easily create various groups of semantically related
types to allow convenient shortcuts. For example, if we have more
than just two coordinates say we add Z, W, T it would be annoying
to explicity define the equality signatures for all permutations
of those types even though we want them to be comparable. So we
first create a Coordinate type then copy it

copy Integer Coordinate
copy Coordinate X
copy Coordinate Y
copy Coordinate Z
copy Coordinate W
copy Coordinate T

and now explicity add implicit coersion signatures

() : X -> Coordinate
() : Y -> Coordinate
() : Z -> Coordinate
() : W -> Coordinate
() : T -> Coordinate

which now allows implicit mutual equality comparison (and any other
operators) between X, Y, Z, W, T and Coordinate since they are now
implicitly coerced to Coordinate. Here we only had to explicitly add
only a linear number of implicit coersion operators instead of a
combinatorial number of equality signatures.

KHD

#39

Tegiri Nenashi wrote:

Quote:

On Feb 21, 3:05 am, Jan Hidders <hidd... (AT) gmail (DOT) com> wrote:

On 20 feb, 03:40, David BL <davi... (AT) iinet (DOT) net.au> wrote:
... E.g. a relation has an attribute

containing circles and you must allow it to be addressed using either
circle or ellipse.

Indeed. But the header would contain only Ellipse, and all subtypes,
including Circle, would be implied. ...

Ellipse-Circle example is unconvincing. Both are conic sections and it
is natural to suggest that the design would greatly benefit from
introducing a single class instead of many. The only objection is that
certain methods being constrained to subtypes (such as Circle) might
greatly benefit in performance.

What's the radius of an ellipse?

The differences are conceptual and logical not just physical.

#40

Bob Badour wrote:

Quote:

Tegiri Nenashi wrote:

On Feb 21, 3:05 am, Jan Hidders <hidd... (AT) gmail (DOT) com> wrote:

On 20 feb, 03:40, David BL <davi... (AT) iinet (DOT) net.au> wrote:
... E.g. a relation has an attribute

containing circles and you must allow it to be addressed using either
circle or ellipse.

Indeed. But the header would contain only Ellipse, and all subtypes,
including Circle, would be implied. ...

Ellipse-Circle example is unconvincing. Both are conic sections and it
is natural to suggest that the design would greatly benefit from
introducing a single class instead of many. The only objection is that
certain methods being constrained to subtypes (such as Circle) might
greatly benefit in performance.

What's the radius of an ellipse?

The differences are conceptual and logical not just physical.

Must confess that I probably have a big mental block about another
aspect of type theory, eg., the very mention of it usually makes me ask
myself how to record the value of one-third of a meter (which might be
why I usually try to keep out of typing discussions). Probably my own
inadequacy, not having grown up in a metric country it never occurred to
me to wonder what one-fifth of a foot is. International agreement about
25.4 mm's being an inch doesn't help. Seems to me that the application
requirement always trumps questions of precision and any practical dbms
needs to require/allow decimal places for numeric types. While I
sympathize with Keith D's wish to eliminate the 'name,type' double, I
think that practical issues require not only so-called 'possreps' but
also what I think of as a 'name,type,use' triples. What a mess!

As for having just types, I still think that Codd introduced his
attribute names because of relations that can have two 'columns' of the
same type. I think Keith D is arguing against this and if I'm right
about that, I'd like him to deal with that case, not to say it can't be
done, just that I'd like to see whether his "copy" in a language is a
better tool.