home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / lisp / 2916 < prev    next >
Encoding:
Text File  |  1992-11-19  |  3.3 KB  |  73 lines
  1. Newsgroups: comp.lang.lisp
  2. Path: sparky!uunet!ornl!rsg1.er.usgs.gov!darwin.sura.net!spool.mu.edu!mixcom.com!wstar.mixcom.com!jpf
  3. From: jpf@wstar.mixcom.com (John P. Flanagan)
  4. Subject: Re: *READ-SUPPRESS* and #P syntax
  5. Message-ID: <1992Nov19.170212.370@wstar.mixcom.com>
  6. Date: Thu, 19 Nov 1992 17:02:12 GMT
  7. References: <1992Nov15.210151.1062@wstar.mixcom.com> <1e934iINNaod@early-bird.think.com> <1992Nov18.000646.1180@wstar.mixcom.com> <1ee4m8INNbmt@early-bird.think.com>
  8. Organization: WaveStar Technology
  9. Lines: 62
  10.  
  11. barmar@think.com (Barry Margolin) writes:
  12.  
  13. >In article <1992Nov18.000646.1180@wstar.mixcom.com> jpf@wstar.mixcom.com (John P. Flanagan) writes:
  14. >>barmar@think.com (Barry Margolin) writes:
  15. >>>My interpretation of *READ-SUPPRESS* is that when it doesn't say something
  16. >>>operates differently from normal, it should operate the normal way.  Thus,
  17. >>
  18. >>Maybe it's the cloudy weather affecting my judgement, but since nearly
  19. >>all sharp reader macros behave a certain way when *read-suppress* is
  20. >>non-nil, why then would you assume that a sharp reader macro that slipped
  21. >>through the specification net wouldn't behave in a similar manner?
  22.  
  23. >I based my assumption on the fact that CLtL and the dpANS specifically list
  24. >only a small number of sharpsign macros in the the description of
  25. >*READ-SUPPRESS*, and make no mention of a general default effect of setting
  26. >this variable.  When interpreting a language standard (AKA "language
  27. >lawyering"), it's generally not appropriate to extrapolate from specific
  28. >instances to general cases.
  29.  
  30. According to my copy only three sharp reader macros, #C, #(, and #',
  31. were left out of the description for *READ-SUPPRESS*, that's hardly a
  32. small number!  We have twelve *specific* reader macro examples to ponder
  33. in that description of *READ-SUPPRESS*; excluding #=, all produce nil when
  34. *READ-SUPPRESS* is non-nil.  How much extrapolation is required to properly
  35. reconcile the behavior of #C, #(, or #' given this kind of evidence?
  36.  
  37. >>Normally these two expressions produce a vector of two elements, the symbols
  38. >>foo and bar, but when *read-suppress* is non-nil we get this instead?
  39. >>
  40. >>    #1A(foo bar)
  41. >>    => nil
  42. >>
  43. >>    #(foo bar)
  44. >>    => #(nil nil)
  45. >>
  46. >>Isn't this a bit inconsistent (if not confusing)?
  47.  
  48. >I agree that it's inconsistent and confusing, but I also believe it's
  49. >implied by CLtL.
  50.  
  51. One man's implication is another man's extrapolation?  ;-)
  52.  
  53. >Actually, I'm considering suggesting a more general change:
  54.  
  55. >    When *READ-SUPPRESS* is true, READ, READ-PRESERVING-WHITESPACE, and
  56. >    READ-DELIMITED-LIST all return NIL; however, they continue to parse the
  57. >    representation of an object in the normal way, in order to skip over
  58. >    the object.  Any standard read macro that is defined to read an object
  59. >    or token will do so, but not signal an error if the object read is not
  60. >    of an appropriate type or syntax.
  61.  
  62. >Sound reasonable?
  63.  
  64. Yes, very much so, but you're already tempting fate (**EXTRAPOLATION**)
  65. by not mentioning READ-FROM-STRING!
  66.  
  67. -jpf.
  68. -- 
  69.    __________________________________________________________________________
  70.    WaveStar Technology           WaveStar Common Lisp        John P. Flanagan
  71.    W344 N6855 Bayberry Court     ANSI-12.24, X3J13/92          (414) 367-5014
  72.    Oconomowoc, WI  53066         HPUX-800/700/400/300    jpf@wstar.mixcom.com
  73.