home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / lisp / 2859 < prev    next >
Encoding:
Text File  |  1992-11-11  |  2.1 KB  |  58 lines
  1. Path: sparky!uunet!ogicse!emory!sol.ctr.columbia.edu!spool.mu.edu!mixcom.com!wstar.mixcom.com!jpf
  2. From: jpf@wstar.mixcom.com (John P. Flanagan)
  3. Newsgroups: comp.lang.lisp
  4. Subject: Re: *READ-SUPPRESS* and #P syntax
  5. Message-ID: <1992Nov11.201954.825@wstar.mixcom.com>
  6. Date: 11 Nov 92 20:19:54 GMT
  7. Article-I.D.: wstar.1992Nov11.201954.825
  8. References: <1992Nov11.014902.6585@kronos.arc.nasa.gov>
  9. Organization: WaveStar Technology
  10. Lines: 46
  11.  
  12. philpot@kepler.arc.nasa.gov (Andrew Philpot) writes:
  13.  
  14. >Should *READ-SUPPRESS* be obeyed when reading literal pathnames using
  15. >#P?
  16.  
  17. Yes!
  18.  
  19. [... stuff deleted ...]
  20.  
  21. >However, strictly speaking, this behavior is allowed by pp. 522 ff. of
  22. >CLtL2.  It appears that the appropriate section of the new dpAns spec
  23. >agrees with CLtl2 in this matter.  I couldn't swear I got to the right
  24. >section, but there was one in dict-reader.tex that mirrored 22.1.2
  25. >pretty well, and I didn't find any reference to #P there.
  26.  
  27. Strictly speaking, I don't think this behavior is allowed.  Section
  28. 2.4.8.14, p.2-33 in the dpANS makes the following statement:
  29.  
  30.        "#P"..." is equivalent to #.(parse-namestring "...")."
  31.  
  32. Now, from the description for *read-suppress* on p.23-22, section 23.2:
  33.  
  34.        "The #. notation reads the following object in suppressed mode but
  35.         does not evaluate it.  The object is discarded and nil is produced."
  36.  
  37. note: IMHO, the dpANS should explicitly mention #P in this section as well.
  38.       Unless I've missed something here, I'll add this suggestion to my
  39.       list of public review comments to be mailed next week.
  40.  
  41. >Is it the intent of dpAns that
  42.  
  43. >  (defvar my-path
  44. >      #+EXCL #P(:type "lisp")
  45. >      #+LUCID #P".lisp"
  46. >      )
  47.  
  48. >can cause an error?
  49.  
  50. No.  I don't think Lucid should be signaling an error in this case.
  51.  
  52. -jpf.
  53. -- 
  54.    __________________________________________________________________________
  55.    WaveStar Technology           WaveStar Common Lisp        John P. Flanagan
  56.    W344 N6855 Bayberry Court     ANSI-12.24, X3J13/92          (414) 367-5014
  57.    Oconomowoc, WI  53066         HPUX-800/700/400/300    jpf@wstar.mixcom.com
  58.