home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!think.com!mintaka.lcs.mit.edu!ai-lab!zurich.ai.mit.edu!gjr
- From: gjr@zurich.ai.mit.edu (Guillermo J. Rozas)
- Newsgroups: comp.lang.scheme
- Subject: Re: Unspecified values in R4RS
- Date: 22 Jan 93 13:12:25
- Organization: M.I.T. Artificial Intelligence Lab.
- Lines: 38
- Message-ID: <GJR.93Jan22131225@chamarti.ai.mit.edu>
- References: <1993Jan21.195822.23639@sqwest.wimsey.bc.ca> <1jn7ou$m5n@agate.berkeley.edu>
- <BRENT.93Jan22085102@rcx1.ssd.csd.harris.com>
- <1jp5n7$nm@agate.berkeley.edu> <OZ.93Jan22114638@ursa.sis.yorku.ca>
- Reply-To: gjr@zurich.ai.mit.edu
- NNTP-Posting-Host: chamartin.ai.mit.edu
- In-reply-to: oz@ursa.sis.yorku.ca's message of Fri, 22 Jan 1993 16:46:38 GMT
-
- In article <OZ.93Jan22114638@ursa.sis.yorku.ca> oz@ursa.sis.yorku.ca (Ozan Yigit) writes:
-
- | Brian Harvey writes:
- |
- | Leaving something unspecified in the standard invites some implementor to
- | give it a "useful" value; and that encourages users of that implementation
- | to use it; and that makes programs non-portable.
- |
- | Are there such implementations? Isn't there some that return
- | #<unspecified>, which is not a "useful" value? Can we point to real
- | implementations, instead of talking about a hypothetical one?
-
- Yes, except that practice precedes freedom. The reason for the
- unspecified (particularly in the case of SET!) was lack of agreement
- among the original authors.
-
- Some implementations (Scheme 311, if I remember correcly), following
- Lisp tradition, returned the stored value. Thus, in these
- implementations
-
- (let ((x 4))
- (set! x (set! x 3))
- x)
-
- returned 3
-
- Other implementations (MIT Scheme, in particular) returned the
- previously stored value, Thus
-
- (let ((x 4))
- (set! x (set! x 3))
- x)
-
- returned 4
-
- Because we could not agree what was better (or whether a third
- alternative was) we left the returned value unspecified so that no
- program abiding by the report could depend on it.
-