home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / lisp / 2908 < prev    next >
Encoding:
Text File  |  1992-11-18  |  2.2 KB  |  57 lines
  1. Newsgroups: comp.lang.lisp
  2. Path: sparky!uunet!think.com!mintaka.lcs.mit.edu!gateway
  3. From: SWM@stony-brook.scrc.symbolics.com (Scott McKay)
  4. Subject: *READ-SUPPRESS* and #P syntax
  5. Message-ID: <19921118191401.5.SWM@SUMMER.SCRC.Symbolics.COM>
  6. X-Unparseable-Date: Wed
  7. Sender: news@mintaka.lcs.mit.edu
  8. Organization: LCS news/mail gateway
  9. References: <1992Nov11.014902.6585@kronos.arc.nasa.gov>
  10. Date: Wed, 18 Nov 1992 19:17:09 GMT
  11. Lines: 44
  12.  
  13.     Date: Tue, 10 Nov 1992 20:49 EST
  14.     From: Andrew Philpot <philpot@kepler.arc.nasa.gov>
  15.  
  16.     Should *READ-SUPPRESS* be obeyed when reading literal pathnames using
  17.     #P?
  18.  
  19. I am no dpANS language lawyer, but it certainly seems "right" that
  20. *READ-SUPPRESS* should prevent #P from doing syntax-checking on the
  21. literal pathname.
  22.  
  23.     Siutation: My code was trying to read in some files which contain
  24.     references to pathnames using the #P syntax.  Lucid and Franz have
  25.     different syntaxes for the object following the #P.  Lucid allows only
  26.     a string, whereas Franz supports both strings and lists in this
  27.     position.  Lucid signals an error when given an expression of the form
  28.     #P followed by a list, since that violates its #P reader.
  29.  
  30.     So far, so good.  However, in (lucid) lcl4.1b, you can't avoid
  31.     signaling this error when reading a Franz-derived #P pathname.
  32.     Putting a #-LUCID or #+EXCL qualifier in front of the form doesn't
  33.     seem to work; it reads enough to signal the error anyway.
  34.  
  35.     One would imagine that the intent of using READ-SUPPRESS to implement
  36.     the *FEATURES* idea was to avoid signaling errors associated with just
  37.     this kind of implementation-specific extension.
  38.  
  39.     However, strictly speaking, this behavior is allowed by pp. 522 ff. of
  40.     CLtL2.  It appears that the appropriate section of the new dpAns spec
  41.     agrees with CLtl2 in this matter.  I couldn't swear I got to the right
  42.     section, but there was one in dict-reader.tex that mirrored 22.1.2
  43.     pretty well, and I didn't find any reference to #P there.
  44.  
  45.     Is it the intent of dpAns that
  46.  
  47.       (defvar my-path
  48.       #+EXCL #P(:type "lisp")
  49.       #+LUCID #P".lisp"
  50.       )
  51.  
  52.     can cause an error?
  53.  
  54.     -- 
  55.     ---------------------------------------------------------------
  56.              philpot@ptolemy.arc.nasa.gov
  57.