home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / scheme / 2938 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  1.3 KB
  1. Path: sparky!uunet!olivea!spool.mu.edu!agate!anarres.CS.Berkeley.EDU!bh
  2. From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
  3. Newsgroups: comp.lang.scheme
  4. Subject: Re: Unspecified values in R4RS
  5. Message-ID: <1jn7ou$m5n@agate.berkeley.edu>
  6. Date: 21 Jan 93 22:23:26 GMT
  7. References: <1993Jan21.195822.23639@sqwest.wimsey.bc.ca>
  8. Organization: University of California, Berkeley
  9. Lines: 16
  10. NNTP-Posting-Host: anarres.cs.berkeley.edu
  11.  
  12. The article raises two questions, one about "unspecified" and one about EQ?.
  13.  
  14. To the second question, it seems to me that part of the spirit of EQ? is that
  15. it should only take one machine instruction to compute the result.  That's
  16. why EQ? and EQV? are provided as separate mechanisms; EQV? is more "the right
  17. thing" but EQ? is meant to be *fast*!  So if you are proposing some special
  18. mechanism that checks for unspecifiedness and takes extra trouble to return
  19. false, I say that's a bad idea, not because of a wrong answer but because
  20. of the extra trouble.
  21.  
  22. About unspecified values, in my *strong* opinion these should all be
  23. expunged from the standard and replaced with a nonprinting value, and
  24. the procedures that now have unspecified return values should all be
  25. required to return that.  It doesn't really matter for experienced Scheme
  26. programmers, but it's really confusing to a learner who invokes DISPLAY
  27. and sees *two* values printed.
  28.