Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!scramble.lm.com!news.math.psu.edu!chi-news.cic.net!hookup!tank.news.pipex.net!pipex!swrinde!sdd.hp.com!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.96Mar21133700@hplgr2.hpl.hp.com>
In-Reply-To: blume@zayin.cs.princeton.edu's message of 20 Mar 1996 20:45:05 GMT
Date: Thu, 21 Mar 1996 21:37:00 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>
Nntp-Posting-Host: hplgr2.hpl.hp.com
Organization: Hewlett-Packard Laboratories, Palo Alto, CA
Lines: 81

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

|   I don't particularly like it when people misunderstand *on purpose*,
|   just to make a goofy comeback.  (I don't believe that you *actually*
|   misunderstood.)

It is not just a goofy comeback.  We have a fundamentally _different_
definition of what a type is.  To me, types are not static, and
singleton sets qualify as types just as much as sets with larger
cardinality.  To you a type is almost a syntactic property of a
program.

|   Of course, I have to check for `NULL-ness' in ML, but that's not a
|   matter of types.  The empty list has the same type as the non-empty
|   list.  It's called a "sum type" (aka "discriminated union*).

It's not a matter of types _in your definition_.  It is a matter of
types in mine.  To me, PRIME?, EVEN?, NULL? are all similar in this
regard.  Some of them, sometimes, might be statically checkable.  Some
of them might not be, ever.  It is for the implementation, and or
additional tools, to inform me when something is provably
inconsistent, and produce the most efficient code possible given the
information available.  In addition, I can restrict myself to writing
programs where a subset of types is statically checkable, and use
tools that will notify me when the program is inconsistent with this
additional requirement.

|      You are defining the problem away.  You are saying that a type is that
|      which a (particular) type checker checks for.  It is a consistent
|      definition, but also a circular one.
|
|   No, *you* make it circular.  First, there are *properties*.  Some of
|   them can be checked *statically*.  Some languages *choose* to check
|   those properties statically, in which case the properties are
|   *referred to* as types.  The check itself is known as "type-checking",
|   and the part of the compiler that carries it out is called the
|   "type-checker".  Where do you see the circularity here?

You still haven't defined them.  Are semi-colons or parentheses types?
They are statically checkable.  What is a property?  Even assuming a
vague definition, are they properties _of_ objects or of
variables/identifiers?

|      To me a type is a set of _objects_ (a loaded term).  In particular,
|      this means that membership is not time-variant, since object identity
|      is not time-variant.  What do I mean by this?  Merely that if one
|      object is of some type now, it will continue to be of that type for
|      ever, no matter what the future course of the computation.  Similarly
|      if it is not of that type now, it will never be.
|
|   Your definition requires the concept of object identity, which can be
|   problematic for languages that don't have object identity.  BTW, the
|   mandatory object identity for procedures in Scheme is a major pain in
|   the *** (for the optimizer), and on top of that mostly useless for
|   practical purposes.

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).
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.

BTW, I have never found object identity for procedures to be a pain at
all.  The optimizers that I have written distinguish between "reified"
uses of a procedure and those that do not require "reification".  The
optimizers must guarantee that all such reifications refer to the same
object (unless they can prove that they can't meet, but I've never
tried to do this).  For those uses that do not require reification
(the vast majority in my experience), the optimizer is free to do
whatever it wants.

|      At any rate, I was only pointing out that your previous post, where
|      you apparently claimed that ZERO? checked for identity with a
|      particular object was incorrect.
|
|   I didn't post that.

You are right.  It was Scott Draves.  My mistake.
