Prev: AVG Internet Security 9.0 key till 2018
Next: Richard P Gabriel's home page
From: Joshua Taylor on 13 Aug 2010 15:48
On 2010.08.13 3:31 PM, Joshua Taylor wrote:
> I'm not a CLISP maintainer either, but it looks like passing an output stream
> to COMPILE-FILE will cause the fasl to be written directly to the stream (without
> opening up another output-stream associated with the file).

Indeed, here's a case that illustrates the difference in CLISP:

(let* ((l "path-tst-compile-file-pathname.lisp")
(f (compile-file-pathname l)))
(with-open-file (ls l :direction :output :if-exists :supersede)
(format ls "(defun f () t)~%"))
(list
(with-open-file (fs f :direction :output :if-exists :supersede)
(format fs #1="first line") (terpri fs)
(compile-file l :output-file fs)
(prin1-to-string fs))
(with-open-file (fs f :direction :input)
(string= #1# (read-line fs)))))

results in no errors. However, if we pass (pathname fs) to compile-file
rather than fs, i.e.,

(let* ((l "path-tst-compile-file-pathname.lisp")
(f (compile-file-pathname l)))
(with-open-file (ls l :direction :output :if-exists :supersede)
(format ls "(defun f () t)~%"))
(list
(with-open-file (fs f :direction :output :if-exists :supersede)
(format fs #1="first line") (terpri fs)
(compile-file l :output-file (pathname fs)) ; ****
(prin1-to-string fs))
(with-open-file (fs f :direction :input)
(string= #1# (read-line fs)))))

OPEN: #<OUTPUT BUFFERED FILE-STREAM CHARACTER
#P"/Users/tayloj/path-tst-compile-file-pathname.fas"> already points to file #1="/Users/tayloj/path-tst-compile-file-pathname.fas", opening the file
again for :OUTPUT may produce unexpected results
[Condition of type SYSTEM::SIMPLE-FILE-ERROR]

This seems like a useful behavior in practice (it avoids the strange
output you'd see otherwise), but it does complicate the notion of
pathname designator a bit, since fs and (pathname fs) designate the same
pathname. On designators the HS says (1.4.1.5):

"Except as otherwise noted, in a situation where the denoted object might
be used multiple times, it is implementation-dependent whether the object
is coerced only once or whether the coercion occurs each time the object
must be used."

This is an interesting case since the designator apparently isn't coerced
even once---the designated pathname is never even produced (not even "only
once", heh).

//JT

First  |  Prev  | 
Pages: 1 2
Prev: AVG Internet Security 9.0 key till 2018
Next: Richard P Gabriel's home page