shap@POLYA.STANFORD.EDU ("Jonathan S. Shapiro") (05/25/89)
Very well. I hereby specify an object whose name is #UNSPECIFIED 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 conditions. 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. Jon
mkatz@SESAME.STANFORD.EDU (Morris Katz) (05/26/89)
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 #UNSPECIFIED 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 conditions. 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. Jon 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 follows: 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 standard. 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 katz@polya.stanford.edu
bobg+@andrew.cmu.edu (Robert Steven Glickstein) (05/27/89)
> Excerpts from ext.nn.comp.lang.scheme: 25-May-89 Scheme Digest #125 > Jonathan Shapiro@POLYA.S (631) > Very well. I hereby specify an object whose name is > #UNSPECIFIED I second the motion. I am currently designing ELSIE (the "Embedded Lisp [Scheme] Interpreter, `ELSIE'"), and I'd rather not have to make arbitrary decisions about what SET! returns (for instance). (Actually, set! is a bad example, since I believe it should return the new value, which I guess I'm proposing for R4RS, but you get the idea.) -Bob Glickstein
mkatz@SESAME.STANFORD.EDU (Morris Katz) (05/30/89)
Date: 27 May 89 01:47:09 GMT From: Robert Steven Glickstein <bobg+@andrew.cmu.edu> > Excerpts from ext.nn.comp.lang.scheme: 25-May-89 Scheme Digest #125 > Jonathan Shapiro@POLYA.S (631) > Very well. I hereby specify an object whose name is > #UNSPECIFIED I second the motion. I am currently designing ELSIE (the "Embedded Lisp [Scheme] Interpreter, `ELSIE'"), and I'd rather not have to make arbitrary decisions about what SET! returns (for instance). (Actually, set! is a bad example, since I believe it should return the new value, which I guess I'm proposing for R4RS, but you get the idea.) -Bob Glickstein Since the return value is left unspecified, you don't have to make an arbitrary decision. Simply created #UNSPECIFIED in your implementations and return it. This is completely consistent with the current standard. Just don't force #UNSPECIFIED on the rest of our implementations. Morry Katz katz@polya.stanford.edu
will@uoregon.uoregon.edu (William Clinger) (05/31/89)
For the sake of portability, I would like to plead with anyone who is
inventing a syntax for random values as part of a new Scheme system to use
the #! syntactic convention instead of grabbing yet another #X syntax,
where X is a character. For example, I plead with you to say #!unspecified
instead of #unspecified.
Two reasons:
1. #!unspecified is already supported by several implementations.
More generally, there is a tradition of using similar #! syntaxes
for miscellaneous constants.
2. Within the Lisp world, most #X syntaxes are traditionally reserved
for user-defined extensions to the syntax accepted by the read
procedure. The syntax of Scheme reflects this tradition, in which
the first character following the # indicates the nature of the
syntactic extension. Note that there are only 26 (or 52) possible
#X syntaxes where X is a letter, and that Scheme has already
taken 8 (or 16) of these: #t, #f, #e, #i, #b, #o, #d, and #x.
This causes no problem for Scheme systems that don't support
user-defined #X syntaxes, but the existence of systems that do
support user-defined #X syntaxes makes it less likely that syntaxes
like #unspecified will ever become standard.
Peace,
William ClingervanMeule@ALLEGHENY.SCRC.SYMBOLICS.COM (Andre van Meulebrouck) (06/22/89)
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
#UNSPECIFIED
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
conditions.
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.
Jon
[Disclaimer: my opinions are purely my own.]
An off-the-cuff comment after seeing the argument posed that way (^^) is: "Why
not? After all there is canonical truth!".
I see a lot of parallels between canonical unspecified and canonical truth.
I'm not taking sides however, because my jury's still out and/or I don't care
enough to get really religious one way or the other about it.
BTW: I think the whole thing with nil vs. () vs. #f got a lot of mental energy
spent on it, and even after all that mind power being focused on that issue, I'm
still not convinced that things are now consistent or appreciably cleaner than
before: the net outcome seems to have hypocrisies of its own such that I'm not
convinced Scheme is truly better off than Common Lisp (on the nil issue) for all
the hubbub and hoopla.