[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Scheme Digest #125

   Date: Thu, 25 May 89 02:27:13 -0700
   From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>

   Very well.  I hereby specify an object whose name is


   Any association between this name and some meaning in your mind is
   coincidental.  I propose that all functions/forms that under some
   conditions currently return an unspecified value should now return a
   value which is EQ? to the value named by #UNSPECIFIED under those same

   Note that you are only in violation of R3RS if you *tell* me that that
   is what you do...

   Seriously: It's a non-damaging change, and there seems to be concensus
   that it is valuable to some part of the community and has no impact to
   speak of on anyone else.

   Let's do it.


It is evident from the recent discussion on unspecified values that many of the
participants have not been present for previous discussions on this subject
(e.g., at Snowbird).  Leaving values unspecified is done for many different
reasons and achieves a series of different goals.  Some of these are as

1)  Not specifying a return value allows different implementations to
experiment with different return values.  Specifying return of the unspecified
object would prevent such experimentation from falling within the Scheme

2)  When the group could not agree on what a function should return, the return
value has sometimes been left unspecified until such time as we could all agree
what the correct return value should be.  Specifying the return value as
unspecified would mean that eventually specifying some specific return value
would require a substantive change in the standard.

3)  Some functions are performed for side effect only and it has been generally
agreed that no sensible return value can be specified for them.  To specify
that such functions return a specific unspecified object would not be a problem
for such functions subject to 4).

4)  Some things have been left unspecified in Scheme in order to allow clever
implementors to build more efficient implementations.  Greater specification of
even return values for some functions could limit the ability to create such
clever implementations.  In such cases, the burden of proof is on those who
want to specify the unspecified object to demonstrate that its advantages
outway its costs in these cases.

There have probably been other reasons for unspecification, but I can't think
of any off the top of my head.  
					Morry Katz