A question about types, sets, and classes arose on the AESIG
mailing list, which is related to the earlier discussion in
this thread. See, in particular, the slides by Peter Aczel. (01)
John (02)
 Original Message 
Subject: Re: [architecturestrategy] Relationship between types, classes
and sets
Date: Wed, 19 Jan 2011 23:54:43 0500
From: John F. Sowa <sowa@xxxxxxxxxxx>
To: architecturestrategy@xxxxxxxxxxxxxxx (03)
Cory, (04)
> The terms “type”, “class” and “set” are used within many modeling
> languages, formal languages and natural language. A precise
> specification of languages involving these terms must have them
> precisely specified. (05)
I agree. (06)
> I have not found a consistent differential between “type” and
> “class”, in many cases they seem to be used as synonyms (07)
There is a good reason why it is hard to distinguish them:
in computer languages that use both terms, there is a direct
correspondence between types and classes: each type is defined
by some specification, and the corresponding class is the set
of all objects for which that specification is true. (08)
> Rick murphy referenced this paper:
>
> http://www.cs.man.ac.uk/~petera/whatisasetleedsnov2010.pdf (09)
These slides by Peter Aczel distinguish the terms 'type', 'class',
and 'set' as used by logicians who talk about higher orders of
infinity. Most of that discussion is irrelevant to AESIG. (010)
I'll just extract a few sentences from Aczel's slides that
represent a broad consensus among logicians about the terms
'type', 'class', and 'set'. I'll delete any sentences that
are irrelevant or too involved to be explained simply.
My inserted comments are in brackets. (011)
*From slide 6,* The classical iterative conception (012)
Zermelo, Scott, Schoenfield, Boolos, Parsons,... (013)
Sets are extensional. (014)
Sets are formed in stages, α, out of elements formed at earlier stages. (015)
A set is formed by collecting together (into a whole) its elements. (016)
There are lots of stages. (017)
[These are mathematically generated sets, not the usual finite sets
one encounters in computer systems. Finite sets could be generated
by iteration, but they could also be stated in a simple list.] (018)
*From slide 8,* Types, sets and classes (019)
Any discussion concerning the concept of set must distinguish
between the three distinct notions of type, set and class. (020)
The notion of type is perhaps best taken as a premathematical
philosophical notion. [It is an informal concept that various
logicians have formalized in different ways.] (021)
The notion of set of ZF [ZermeloFrankel set theory, one of the most
commonly used versions] is an iterative combinatorial notion. (022)
The notion of class is a logical notion  the extension of
a predicate. [In short, given a predicate P(x), the class of P
consists of all x's for which P(x) is true.] (023)
*From slide 9,* Types and Classes (024)
A mathematical object is always given as an object of some type. (025)
We write a:A for the judgment that a is an object of type A. (026)
A class on a type is the extension of a propositional function
on the type [i.e., a predicate that ranges over objects of the
given type]. (027)
If B is a propositional function on the type A then its extension
is the class C = {x : A  B(x)}. [i.e., all x's of type A
for which B(x) is true.] (028)
*End of selections.* (029)
The fine points in later slides aren't relevant to any issues that
have been discussed in AESIG. (030)
Summary: (031)
1. A set is extensional: it is uniquely determined by its elements. (032)
2. Type is an informal notion has been formalized in different ways.
But a very common and useful way is to choose some predicate
that specifies the type. (033)
3. A class is the extension of some predicate. (034)
4. Every set is a class, but some classes could be too big to
be sets  but those are hyperinfinite monsters that are
irrelevant to computer systems. (035)
> If an object could change types... (036)
No object can "change" types without becoming a different object.
The number 1 of type Integer belongs to the class for which the
predicate Integer(1) is true. If that integer is mapped to a
floating point number 1.0, the predicate Integer(1.0) is false.
The object 1 didn't "change" to 1.0, it was mapped to a different
object of a different type. (037)
John (038)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontologforum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontologforum/
Unsubscribe: mailto:ontologforumleave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgibin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontologforum@xxxxxxxxxxxxxxxx (039)
