Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!cs.utexas.edu!uunet!news.cygnus.com!nntp!lord
From: lord@cygnus.com (Tom Lord)
Subject: Re: three R4RS/IEEE questions
In-Reply-To: Ken Dickey's message of 13 Dec 1994 22:05:33 GMT
Message-ID: <LORD.94Dec14223917@cygnus.com>
Sender: news@cygnus.com
Nntp-Posting-Host: cygnus.com
Organization: Cygnus Support
References: <LORD.94Dec7141015@x1.cygnus.com> <3cl5rd$9u5@apple.com>
Date: Thu, 15 Dec 1994 06:39:17 GMT
Lines: 88



Thank you Jake Donham, Will Clinger, Ken Dicky and probably others.
Here is my new understanding of (), #f, IEEE, and R4RS:


	1. It is consistent with the standard to have non-standard
	   values which are false.  Section 6.1 is a positive
	   indication that this is so.

	   The wording in section 3.2 can be read to suggest a
	   contrary conclusion, but such a reading is undermined by
	   the text itself:
	   
		- The relevant part of 3.2 purports to be a paraphrase of 
		  section 6.1  ("As explained in 6.1,...")
	   
		- The purpose of 6.1 is to specifiy the boolean type,
		  but the purpose of 3.2 is only to explain how the words
	 	  "true" and "false" are used in the document.

		- Elsewhere we see phrases like (in 4.1.5) 
		  "If it yeilds a true value (see section 6.1)..."
	   	  or in 4.2.1, where AND is being specified:
		  "...the first expression that evaluates to a
	  	  false value (see section 6.1)". Evidently 6.1 is the 
		  place to look to grok the concept of true and false
	 	  values.

	2. The disjointedness of types applies to all objects; not
	   merely the standard objects mentioned explicitly by the standard.
	   IEEE adds NULL? to the list of disjointedness predicates.
	   Thus, the possibility of a value satisfying NULL? and BOOLEAN?
	   is precluded in `standard Scheme'.

	3. Multiple end-of-list values are permitted
	   (because there is no langauge which prohibits it).

	4. Objects which can be distinguished using standard procedures
	   should be neither eq? nor eqv?.

	5. From the above, we can conlude that a standard conforming
	   implementation can include a distinct non-standard value which
	   is both an end of list value, and a false value (but not
	   a BOOLEAN? value).  Standard programs running in such
	   an implementation would never generate this value and would
	   run according to the specification of the standard(s).

	6. A standard conforming interpreter is, of course, free to 
	   offer alternative environments which are not standard conforming.
	   (Nobody disputes this, that i know of.)

An interpreter which obeys the principles listed above can correctly
run every standard Scheme program there is (and some other programs
besides).  This condition is usually described as "standard conforming".

Such an implementation is also consistent with the stated plans of the
Guile project, to produce an interpreter capable of running programs
which presume that the values denoted by "()" and "#f" are the same.

-t

p.s.: for consistency with the definitions of AND, OR, COND and IF,
      the definition of NOT ought to be changed by one word.  It says:

	(not <obj>)			essential procedure
	NOT returns #t if <obj> is false, and returns #f otherwise.

      It would be more internally consistent to say:

	NOT returns #t if <obj> is a false value, and returns #f otherwise.

      Without this change, IF, AND, OR, and COND are specified to deal
      correctly with a non-standard false values, but NOT is said, by
      virtue of the definition of "false" in 3.2, to recognize only #f
      as false.   

      I think it is a reasonable presumption that this difference
      between NOT and the special syntaxes is accidental.  The definition
      of NOT occurs in section 6.1 itself, thereby making it unlikely
      that the definition of "false" from section 3.2 is being counted on.

      
--
----

If you would like to volunteer to help with the GNU extension language
project, please write to lord@gnu.ai.mit.edu.
