Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!news.mathworks.com!news.kei.com!nntp.coast.net!col.hp.com!news.dtc.hp.com!hplntx!hplntx.hpl.hp.com!gjr
From: gjr@hplgr2.hpl.hp.com (Guillermo (Bill) J. Rozas)
Subject: Re: null? vs zero?
Sender: news@hpl.hp.com (HPLabs Usenet Login)
Message-ID: <GJR.96Mar23134937@hplgr2.hpl.hp.com>
In-Reply-To: blume@zayin.cs.princeton.edu's message of 21 Mar 1996 23:07:27 GMT
Date: Sat, 23 Mar 1996 21:49:37 GMT
Reply-To: gjr@hpl.hp.com
References: <SPOT.96Mar15200113@sandoz.slip.cs.cmu.edu> <4ij17q$b2j@sifon.cc.mcgill.ca>
	<SPOT.96Mar18170504@sandoz.slip.cs.cmu.edu>
	<GJR.96Mar18173433@hplgr2.hpl.hp.com>
	<BLUME.96Mar19093430@zayin.cs.princeton.edu>
	<GJR.96Mar20105249@hplgr2.hpl.hp.com>
	<BLUME.96Mar20154505@zayin.cs.princeton.edu>
	<GJR.96Mar21133700@hplgr2.hpl.hp.com>
	<BLUME.96Mar21180727@zayin.cs.princeton.edu>
Nntp-Posting-Host: hplgr2.hpl.hp.com
Organization: Hewlett-Packard Laboratories, Palo Alto, CA
Lines: 85

In article <BLUME.96Mar21180727@zayin.cs.princeton.edu> blume@zayin.cs.princeton.edu (Matthias Blume) writes:

|   In article <GJR.96Mar21133700@hplgr2.hpl.hp.com> gjr@hplgr2.hpl.hp.com (Guillermo (Bill) J. Rozas) writes:
|
|      What is a property?
|
|   It is a unary relation over values of your language.  Why do we have
|   to argue over this?  I know you know that!

No I do not.  I had no idea what you meant by that.  I still don't
know, since in some sense I do not know what you mean by _values_ in
"my" language.  I suspect that if we dig deep enough we will find that
we disagree on some very fundamental assumption, from which everything
else arises.

I am not being finicky.  I _do not_ know what you mean.

At any rate, evenness is a unary relation.  So is null-ness, so is
prime-ness.  Why aren't they types?  I'm very confused.

|
|     Even assuming a
|      vague definition, are they properties _of_ objects or of
|      variables/identifiers?
|
|   Of values.  And when we talk about static type checking, then we often
|   mean the values that a given source-language variable can assume.

A variable can assume the value of an even integer, or a prime one,
etc.  Again, why are some such relations types and not others?

|
|      To me object identity is _fundamental_.  No language that lacks the
|      concept is powerful enough.  To me a programming language must
|      _naturally_ model real-world objects, where all objects have identity
|      (so it cannot be an operation built on top of special objects).
|
|   Sooo---, electrons have an identity?!  That's probably great news for
|   the physicists of the world...  There are *many* things in the world
|   that do not have an identity, most notably various mathematical
|   concepts.

I have never met an electron, so I don't know whether it does or not.
I'm not even sure it is an object, since I consider objects to be
material and electrons are sub-material.

At any rate, they have a form of identity, namely the Pauli exclusion
principe of fermions (particles witn non-integer spin).  Object
identity is a stronger form of such exclusion, but not different.  It
precludes two objects from being in the same space at the same time,
just like any two electrons are precluded from being in the same
quantum state.  If you had said photons, which have spin 0...

Mathematical _concepts_ are definitely not objects, although their
_representations_ may be.

From the dictionary on my desk (The American Heritage Dictionary of
the English Language)

object: Anything perceptible by the senses, a _material thing_.
concept: An _idea_, esp. an abstraction drawn from the specific.

|
|      Thus objects must (conceptually) persist -- that's why I like garbage
|      collection.  I must also be able to identify them by comparing them to
|      other objects, etc.  I know you disagree in this, but your point of
|      view is not better, merely different.
|
|   I do not say we need to abandon *all* object identity.  But for things
|   like cons cells and closures they are an unnecessary pain and no win.

I disagree.  I find it incredibly useful.  I have toyed at various
times with the idea of getting rid of such identity, and I always end
up deciding that it is too cumbersome for generic utilities.

|   In ML I can always tag things with a `ref ()' to give it identity if I
|   *really* need to.

Yes, I know you can build it.  It's even not too inconvenient.  But
again, it has the same problem.  It requires foreknowledge and
prescience.  Thus the generic-utility implementor that does not know
about your particular representation can't rely on it being there (or
how) and cannot handle your "objects".  That's why I think it needs to
be primitively in the language.  You can always abstract over it if
you wish.
