home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / scheme / 2944 < prev    next >
Encoding:
Internet Message Format  |  1993-01-22  |  2.3 KB
  1. Path: sparky!uunet!usc!sdd.hp.com!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. Date: 22 Jan 1993 16:00:39 GMT
  6. Organization: University of California, Berkeley
  7. Lines: 33
  8. Message-ID: <1jp5n7$nm@agate.berkeley.edu>
  9. References: <1993Jan21.195822.23639@sqwest.wimsey.bc.ca> <1jn7ou$m5n@agate.berkeley.edu> <BRENT.93Jan22085102@rcx1.ssd.csd.harris.com>
  10. NNTP-Posting-Host: anarres.cs.berkeley.edu
  11.  
  12. In response to my suggestion that "unspecified" be replaced by "nonprinting",
  13. brent@ssd.csd.harris.com (Brent Benson) writes:
  14. >Implementations are free to return a non-printing value for
  15. >unspecified return values.  It seems like a bad idea to mandate a
  16. >non-printing unspecified return value when there is no clear evidence
  17. >that it is the most useful or understandable.  I think it's a good
  18. >idea to let implementors try different ideas and see what works best.
  19. >Implementators and users will gravitate towards what works.
  20.  
  21. It seems to me that this argument could be made about almost any issue.
  22. For example, why specify that (car '()) should be an error?  Some people
  23. like it better if (car '()) --> ().  So let's have the standard say that
  24. it's unspecified.  Pfui; then nobody can understand anyone else's programs.
  25.  
  26. Leaving something unspecified in the standard invites some implementor to
  27. give it a "useful" value; and that encourages users of that implementation
  28. to use it; and that makes programs non-portable.
  29.  
  30. But my real concern comes from the fact that I've been writing a textbook
  31. using Scheme.  Every time there is an "unspecified" in the standard, the
  32. text ends up with an ugly explanation of why we can't tell the poor reader
  33. what happens when you enter this expression.
  34.  
  35. I can see that there are a few cases in which it would impose a burden on
  36. implementations to get rid of all the unspecifieds, such as some of the
  37. more obscure ones in EQ? and EQV?.  But those don't bother me so much.
  38. It's the easy cases, like DISPLAY, SET!, DEFINE, and so on, that I want to
  39. get rid of.
  40.  
  41. It's not as if DEFINE were only invented last week, so we need another year
  42. or two of experience with it before we can have opinions about what value
  43. it should return.  If we don't know by now, then it doesn't matter, and you
  44. might as well humor me!  :-)
  45.