Main Page | Report Page

 

  Computers Forum Index » Computer Languages (Lisp) » COMPILE-FILE argument :OUTPUT-FILE...

Author Message
Joshua Taylor...
Posted: Fri Aug 13, 2010 11:48 pm
 
On 2010.08.13 3:31 PM, Joshua Taylor wrote:
Quote:
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
 
 
Page 1 of 1    
All times are GMT
The time now is Tue Sep 02, 2014 2:00 am