On 17 feb, 21:00, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:
You seem to be linking being untyped and representing functions/
operations with predicates. Can I ask why? Would you not agree that
one can have one without the other and vice versa?

-- Jan Hidders

On Feb 17, 2:01*pm, Jan Hidders <hidd... (AT) gmail (DOT) com> wrote:
No rationale (other than sharing intuition with more elaborate David
BL explanation). What are types? Is there a foundation that doesn't
involve heavy machinery of category theory?

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. This is
especially evident through the prism of set intersection join (aka
composition) operation...

On Feb 17, 3:46*pm, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:
Let me clarify these ideas. In unnamed perspective attributes are
numbers indicating _relative_ position of each attribute in each
individual relation. One have to devise some drudgery conventions to
be able to compare, say, attribute #5 in the relation Emp with
attribute #2 in the relation Dept. In unnamed perspective Cartesian
Product takes the prime stage with all those mathematical snags around
it (non commutativity, non associativity).

With named attributes we operate relation attributes as ordinary sets.
Unfortunately, classic Relational Algebra doesn't make this point
obvious. Natural join unions the attributes, but about the other
Relational Algebra operations? Compare it to relational lattice, where
- generalized union (denoted "v") intersects attribute sets
- ditto inner join (denoted "*")
- outer union ("+", aka D&D <OR>) unions attributes
- unary inversion operation ("`") builds a relation with
"complementary" set of attributes.
These are not some exotic operations, one can suggest a list of very
practical queries involving them:
http://vadimtropashko.wordpress.com/...or-sql-people/

What about other set operations? For example, symmetric difference is
an operation with some notable algebraic properties; do we have an
binary operation operation over relations that takes a symmetric
difference of attributes? Yes, in fact there are several of them
http://vadimtropashko.wordpress.com/...and-set-joins/
the most distinguished among these being set intersection join (aka
composition). I wonder if the whole theory shouldn't be recast in
semiring form of natural join and composition...

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

Except that I'm not proposing "positional attributes" so I fail
to see the relevance of your point? 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.)

Second, I'm pointing out that if the answer to that question is
"none", then a set of unique types is sufficient to logically
identify attributes and names are not needed. Third, operating
on types for such things as "rename" etc is really not any more
difficult than for attribute names (given the proper tools).

Not in what I'm proposing. There is no "positional" anything.
Instead I simply claim, you need either unique names or unique
types. You do not need both. Having unique names instead of
unique types MIGHT BE convenient especially giving the paucity
of domain support these days, but it is not, in principle,
necessary.

Your "positional" points seem like a distraction or red herring.

KHD

On Feb 17, 10:00*pm, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:
Thanks for the reference.

I don't have a problem with such a procedural implementation, but
hiding the types you used to implement the system prevents the user
from extending the model for their needs, unless they can drop down to
the source code and recompile it, but then they can also break it.
The ideal would be a system which is both adaptable and safe.

The actor-like model of delegating to the operand is bad because
operands can override and implement behaviour as they choose. For
example, you won't be able to guarantee that x + y = y + x, since y
may be a user-created value in the domain of Plus which (improperly)
overrides the logic for addition to concatenate the digits.

On Feb 18, 8:08*am, Keith H Duggar <dug... (AT) alum (DOT) mit.edu> wrote:
Your idea doesn't eliminate attribute names, it just delegates it to
the type namespace. I think your copy method should rather be called
aliasing. The whole model still works as we are familiar with it,
except you can't have Point = {int X, int Y} and PointF = {float X,
float Y}. You would either have to make the types the same or choose
different names for the conflicting attributes.

Nilone <reaanb (AT) gmail (DOT) com> writes:

Exactly. Given that, I don't see what is gained.

--
\ “Intellectual property is to the 21st century what the slave |
`\ trade was to the 16th.” —David Mertz |
_o__) |
Ben Finney

On Feb 18, 3:36 am, Nilone <rea... (AT) gmail (DOT) com> wrote:


A typeless language can simply reference built-in or predefined sets
and operators by name. The crucial point is that all sets and
operators (whether built-in or user defined) don't have any concept of
a type.

E.g. there could be a built-in set named Z3 that's implicitly defined
as follows:

Z3 = { 0,1,2 }

There could be a built-in operator named + implicitly defined as the
triple:

( (Z3xZ3), Z3, { ((0,0),0), ((0,1),1), ..., ((2,2),1) }

A language could allow a user-defined function named F:

let F = (Z3, Z3, (lambda x.x+x))

F has domain Z3, co-domain Z3 and graph {(0,0),(1,2),(2,1)}. F itself
doesn't have a type.

Since this language has gone to the trouble to represent domains and
co-domains for the operators it is very similar to a typed language.
A compiler can validate the code or make use of optimal hardware
encodings of elements of the built-in sets.

There is no problem referring to built-in sets like the integers or
the set of all finite strings. These are countably infinite so it is
possible to encode any given element in finite memory space.

On Feb 17, 7:29 pm, David BL <davi... (AT) iinet (DOT) net.au> wrote:
I've jumped in and had a go at defining a typeless language that can
specify a database schema in a set theoretic way...


Sets
----

Let

union(S)

denote the union over each element of S (S is a set of sets)

Let

powerset(X)

denote the set of all subsets of X.


Function graphs
---------------

Let

functiongraphs(D,C)

denote the set of function graphs with domain D and codomain C. i.e.

{ G | G is a subset of D x C where
for each x in D exists unique y in C
such that (x,y) in G
}

Let G be in functiongraphs(D,C). Then

dom(G) denotes D
range(G) denotes { y in C | (x,y) in G }

If (x,y) in G then G(x) denotes y.

Note that given G there are many codomains C satisfying G in
functiongraphs(D,C). Therefore we cannot define codomain(G).

If D,C are sets then functiongraphs(D,C) is necessarily a set
according to the axioms of ZFC. We cannot avoid codomains by defining
functionsgraphs(D) over all possible codomains because that is not a
set under ZFC.


Function graph projection
-------------------------

Let G be a function graph with domain D and let D' be a subset of D.
Then

proj(G,D')

denotes the projection of G onto domain D'. i.e.

proj(G,D') =
{ (x,y) in G | x in D' }


Functions
---------

Let

functions(D,C)

denote the set of functions with domain D and codomain C. i.e.

functions(D,C) = { (D,C,G) | G in functiongraphs(D,C) }

Let f = (D,C,G) and (x,y) in G. Then

dom(f) denotes D
codom(f) denotes C
range(f) denotes range(G)
graph(f) denotes G and
f(x) denotes y.


Function projection
-------------------

Let f = (D,C,G) be a function and D' be a subset of D. Then

proj(f,D')

denotes the projection of f onto domain D', keeping the same co-
domain. i.e.

proj(f,D') = (D', C, proj(G,D'))


Tuples
------

Let A be a functiongraph representing a set of attributes, where for
each (N,D) in A, N represents an attribute name and D represents an
attribute domain (a set). Note that the attribute names are
necessarily distinct by definition of a functiongraph.

Then

tuples(A)

denotes the set of tuples where each tuple is formally a function
graph that maps attribute names into elements of their respective
domains i.e.

tuples(A)
=
{ t in functiongraphs(dom(A),union(range(A))) |
for each (N,D) in A, t(N) in D }

Note that tuples are function graphs not functions because we don't
want to say two tuples are distinct just because of differing
attribute domains.


Relations
---------

Let

relations(A)

denote

powerset(tuples(A))


Key constraints
---------------

Let A be a given functiongraph representing a set of attributes. Let
K be a given subset of powerset(dom(A)) (i.e. sets of sets of
attribute names). Then

relations(A,K)

denotes

{ r in relations(A) |
for all k in K,
for all t1, t2 in r,
proj(t1,k) = proj(t2,k) => t1 = t2
}


Example
-------

A database value is a tuple that maps relation name to relation value.

mydatabaseschema =
tuples
(
{
(
employee,
relations
(
{
(name,string),
(birthdate,date)
},
{
{name}
}
)
}
)
)

On Feb 18, 9:51*am, Ben Finney <bignose+hates-s... (AT) benfinney (DOT) id.au>
wrote:
Nor do I, but I'll accept any definition which doesn't fundamentally
break the model. I'm thinking "someone might implement it this way" -
being flexible about the requirements could make it happen sooner.