Re: Value (was: Mixing OO and DB)
- From: David BL <davidbl@xxxxxxxxxxxx>
- Date: Sun, 24 Feb 2008 19:49:28 -0800 (PST)
On Feb 24, 3:56 am, Marshall <marshall.spi...@xxxxxxxxx> wrote:
On Feb 23, 3:55 am, mAsterdam <mAster...@xxxxxxxxxxx> wrote:
For what it's worth, lately when I think of "value", I just think
"a member of a set."
Is it right to say: you are trying to avoid 'value' as primitive term?
If so may I ask why?
Lately I am viewing things through the lens of set theory.
Set theory already has its primitive terms: "set" and the
membership relation. These are sufficient for its needs.
Value can be defined in those terms, so no need to add
an additional primitive term. (And we want to minimize
the primitives.)
I've been thinking that when we say that a (value) type is a set plus
operators on the elements of the set, we should qualify that and say
by definition a type must be unique up to isomorphism, and as far as a
computer scientist is concerned it is only necessary to think of the
elements as being distinguished in the context of the given type. ie
give up on absolute identity and instead embrace relative identity.
Basically I'm saying that the set elements really map to equivalence
classes in order to account for this concept of uniqueness (only) up
to isomorphism. Putting it another way, when two systems are
designated as isomorphic under a particular isomorphism (= bijection
that is consistent with the operators), the isomorphism tells us when
the elements from the respective systems belong to the same
equivalence class. In fact I suggest that this could technically be
regarded as a subtle difference between element and value (=
equivalence class). Of course it is common practice to use a
representative element to stand for an equivalence class which blurs
the very distinction I'm making. As a result I don't think it is
terribly practical to distinguish between values and elements of
sets. Alternatively we could say by definition elements of sets
*are* equivalence classes to deal with the non-uniqueness issue. I'm
sure that's what we mean when we talk about *the* integers without
further qualification.
The formalism of the type system depends on the relationships amongst
"things" (expressed through sets and operators) and the "things" are
associated with elements of sets and take a back seat role in the
following sense: an element cannot be assumed to exist and have
independent meaning in any absolute sense - it is defined only
indirectly in its relationships to other elements.
As an example, one cannot attribute meaning to an integer until one
has defined it as a distinguished element of the integers. It is only
the system of the integers (which expresses their algebraic
properties) that captures the mathematical meaning. It is the
uniqueness up to isomorphism which allows us to say *the* integers and
in turn to distinguish particular integers like 17.
I think it is important to carefully understand what is meant by the
uniqueness up to isomorphism. For example, it must not be imagined
that an isomorphism between two isomorphic systems is necessarily
uniquely defined. Consider a finite set X with no operators. There
can be many bijections to a set Y with the same cardinality.
Nevertheless I think there is a sense in which X can designate a type
that is unique up to isomorphism! We can treat each element of X as a
representative label of an equivalence class for an enumerated type.
I note that in computer science an enumerated type is a widely used
concept. Database theory in particular is commonly concerned with
labeling things.
I find it satisfying that the requirement of uniqueness up to
isomorphism tells us that mathematical abstractions like ring, field,
group, vector space, metric space do not represent types as far as the
computer scientist is concerned, and perhaps could be regarded as
sets of types.
.
- Follow-Ups:
- Re: Value (was: Mixing OO and DB)
- From: Jan Hidders
- Re: Value (was: Mixing OO and DB)
- References:
- Re: Mixing OO and DB
- From: Marshall
- Value (was: Mixing OO and DB)
- From: mAsterdam
- Re: Value (was: Mixing OO and DB)
- From: Marshall
- Re: Mixing OO and DB
- Prev by Date: Re: header part of the value?
- Next by Date: Re: header part of the value?
- Previous by thread: Re: Value
- Next by thread: Re: Value (was: Mixing OO and DB)
- Index(es):
Relevant Pages
|
|