Keith H Duggar <duggar (AT) alum (DOT) mit.edu> writes:

The use of “set of ordered pairs� is telling. Note that the *pairs* are
ordered, while the *set* is not; the attributes are unordered within the
header.

The point of a unique name is to be able to address the attribute.

Without it, there would be no way to distinguish between attributes of
identical types in the header.

There would also be no way to change the type of an attribute without
also changing all the references to that attribute, even ones where the
type is irrelevant.

You think we don't need to uniquely address attributes within a header?

--
\ “Alternative explanations are always welcome in science, if |
`\ they are better and explain more. Alternative explanations that |
_o__) explain nothing are not welcome.� —Victor J. Stenger, 2001-11-05 |
Ben Finney

On Feb 14, 12:41 am, Ben Finney <bignose+hates-s... (AT) benfinney (DOT) id.au>
wrote:
Dude, I think we all know what "set" and "ordered pair" means.

And they are redundant if the types are unique.

Which is why I said you could "copy" identical types to yield unique
but related types.

Finally we arrive at some interesting and useful point. I have two
points in response. First it is wrong that you cannot change the type
without also referring to attribute references and least in many
cases.
Take my point example:

Point2D = {copy Integer X, copy Integer Y}

The attributes are referred to by the semantic types X and Y. So if
I want to change the representation type I simply change the header
declaration to say Real

Point2D = {copy Real X, copy Real Y}

but that's it! Because all the other references are to X and Y not
Integer.

Second, as I said in my original post

so while I agree they can "sometimes be convenient" I'm saying
they are not necessary. Also I think we probably overestimate their
convenience because we are used to dealing with systems that have
painfully limited type systems (domain support) and IDE support.

For example your objection above implies that "changing all the
references" is somehow difficult. That is not the case if you
have a suitably powerful development environment. I change names
and types often in my coding work yet it is rarely painful due
to careful programming and a powerful development toolset.

You think my proposal does not allow you to uniquely address header
attributes? I think you need to try again, perhaps with less of a
focus on "telling us" what sets and ordered pairs are.

KHD

Keith H Duggar wrote:

Perhaps it would help if you explain what a 'copied type' is
and how 'copying types' is more convenient than ordering
or naming different attributes with the same type.

--
Reinier

Keith H Duggar <duggar (AT) alum (DOT) mit.edu> writes:

You didn't say that, but thanks for the explanation. Okay, so the “copy
type� operation yields a type that is identical to the original except
for its name. What problem is being solved by this?

--
\ “Apologize, v. To lay the foundation for a future offense.� |
`\ —Ambrose Bierce, _The Devil's Dictionary_, 1906 |
_o__) |
Ben Finney

On Feb 13, 10:53 pm, Keith H Duggar <dug... (AT) alum (DOT) mit.edu> wrote:
I'm happy to see some activity in here again.

Your suggestion could help to force developers to derive uniquely
named types for their attributes - Name instead of String, Age instead
of Int, and so on. Otherwise, type names aren't descriptive enough
and will result in the annotation of schemata with comments, with all
the associated problems. It'll happen anyway, of course - if
something is optional, people will skip it.

I also see some problems with type checking. Consider the query
"SELECT * FROM Point2D WHERE X = Y". Comparison of the attributes
require that they be the same type (or at least, one should be a
subtype of the other). Distinguishing unnamed attributes require that
they be unique types, which is the reason for copying them, but that
contradicts the comparison requirement.

On Feb 14, 5:22 pm, Nilone <rea... (AT) gmail (DOT) com> wrote:
Indeed. Thanks for joining ;-)

Agreed. This is one way to "encourage" more sensible typing. Of
course it requires good type support which many current vendors
certainly do not provide.

As copies of Integer, both X and Y can be coerced to Integer. So
we can allow either implicit or explicit type coercion. So either
we can allow

WHERE X = Y

by default or require explicit coercion

WHERE Integer(X) = Integer(Y)

by default. And which is allowed or required should again be left
to the type system. So when I declare

copy Integer X

it may by default add both explicit and implicit coercion operators

() : X -> Integer
() : X -> Integer
Integer() : X -> Integer
Integer() : X -> Integer

or perhaps the following equality operators

= : Integer , X -> bool
= : X , Integer -> bool

which would allow the simple WHERE X = Y but one should be able
to disable that for example by "deleting" those operators

delete () : X -> Integer
delete () : X -> Integer

or

delete = : Integer , X -> bool
delete = : X , Integer -> bool

In which case WHERE X = Y is now illegal and one must write the
coercions explicitly such as WHERE Integer(X) = Integer(Y).

KHD

Oops! Duplicated X should have been Y.

should have been

KHD

On Feb 14, 2:38 pm, r... (AT) raampje (DOT) lan (Reinier Post) wrote:
I was hoping I could get away with just a loose intuitive notion for
what it is ;-) If X is a typecopy of Y then X and Y are distinct types
that are mutually coercible and whose extensions are equal. If need be
we can go into much more detail. However, if possible I'd like to
focus on what usefulness names add other than to handle attributes
with the same type?

For example, just for the sake of argument, pretend we are working
in a universe where every attribute of a relation always has a unique
type in that relation. Ie just pretend that there is never a case
where
we want to have two or more attributes in the same relation having the
same type. Now, in this world do we gain anything any usefulness at
all by having attribute names?

I don't know whether it necessarily more convenient but I do believe
it simplifies the relational model. For one, it is often the case that
one already has unique types and thus can already construct a header
without the additional "attribute names". Second, requiring unique
types and reducing the header to a simple set eliminates the need to
define an additional uniqueness constraint across <name,type> pairs.

KHD

On Feb 14, 4:45 pm, Ben Finney <bignose+hates-s... (AT) benfinney (DOT) id.au>
wrote:
It is an alternate solution to the problem of identifying attributes
that we want to have the "same type". One solution is to introduce
"attribute names". Another, the one I'm proposing here, is to enrich
the type system to provide these "type copies" which are distinct but
mutually coercible types. I believe this solution is simpler in some
ways and that often one is already in possession of all unique types
in which case attribute names just "get in the way" to some extent.

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?

KHD

Keith H Duggar <duggar (AT) alum (DOT) mit.edu> writes:

I don't see how it makes a useful improvement.

There needs to be a way to define attribute behaviour, and also to
define them in such a way that attributes can be uniquely addressed
after definition.

The current method to do this is to assign the attribute a type to
implement its behaviour, and a unique name to address the attribute.
Programming languages support this, to the extent that it even matches
the underlying type metaphor of the programming languages themselves.

Your proposal, if I understand correctly, is that attributes would have
a type that must be unique, and the unique type name would be how to
address the attribute. Uniquely-named types could be identical in their
behaviour. Yet there would be no widespread language support for this,
so it would need to have a pretty significant *benefit* over the
existing system to be worth considering.

So far, all I've seen is that it could be made equivalent to the current
metaphor. You claim less complexity, but I don't see that; all you've
done is shift the complexity around. I also don't see where you've made
explicit what the significant benefit of this change would be.

--
\ “Any intelligent fool can make things bigger and more complex… |
`\ It takes a touch of genius – and a lot of courage – to move in |
_o__) the opposite direction.� —Albert Einstein |
Ben Finney