(open :direction :probe ...) vs probe-file
Peter Seibel
(open file :direction :probe) and (probe-file file). Do folks have
particular stylistic preferences? (Or have I missed some distinction?)
-Peter
--
Peter Seibel pe...@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
David Lichteblau
> Unless I've missed something, there's not a lot of difference between
> (open file :direction :probe) and (probe-file file). Do folks have
> particular stylistic preferences? (Or have I missed some distinction?)
OPEN could (must? should?) actually try to open the file for reading.
So there are cases where PROBE-FILE works, but OPEN signals a
"permission denied" error.
Paul F. Dietz
> Unless I've missed something, there's not a lot of difference between
> (open file :direction :probe) and (probe-file file). Do folks have
> particular stylistic preferences? (Or have I missed some distinction?)
OPEN can be instructed to create the file if necessary (:if-does-not-exist).
Paul
Peter Seibel
Yeah. I thought of that but you can also do the same thing with
:direction :output and not writing anything. Though maybe :probe is
better because it's clear that you didn't just forget to write
something? (Just thinking out loud.) Thanks though.
Thomas F. Burdick
> Unless I've missed something, there's not a lot of difference between
> (open file :direction :probe) and (probe-file file). Do folks have
> particular stylistic preferences? (Or have I missed some distinction?)
Ak, I'd consider it aweful style to do something like:
(let ((existsp (with-open-file (s file :direction :probe) s)))
...)
That's just confusing. PROBE-FILE expresses your intention.
WITH-OPEN-FILE/OPEN expresses a different intention. Hell, we have
both NULL and NOT, which are the exact same function, but it's
stylistically useful to have both.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Erik Naggum
| Unless I've missed something, there's not a lot of difference between
| (open file :direction :probe) and (probe-file file).
Is «file» here intended to be «pathname»? Note that both OPEN and
PROBE-FILE accept pathname designators, not just pathnames. Also,
they differ remarkably in the type of the return value.
| Do folks have particular stylistic preferences?
The two functions perform very different functions. The intersection
is actually rather uninteresting. For instance, you may supply OPEN
with :IF-DOES-NOT-EXIST. OPEN returns a stream with a specified
element-type that you should expect to be honored if you pass the same
stream to a later OPEN call. (Not that this expectation is satisfied
everywhere, but at least you can provide the argument explicitly with
:element-type (stream-element-type <stream>).)
| (Or have I missed some distinction?)
I wonder if you are fully aware of the factors you chose to ignore in
order to believe they are so similar.
--
Erik Naggum | Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Peter Seibel
> * Peter Seibel
> | Unless I've missed something, there's not a lot of difference between
> | (open file :direction :probe) and (probe-file file).
>
> Is «file» here intended to be «pathname»? Note that both OPEN and
> PROBE-FILE accept pathname designators, not just pathnames. Also,
> they differ remarkably in the type of the return value.
Yes, I should probably have said "filespec" or "pathspec". I realized
that the return type is different. But it doesn't seem there's much
one can (usefully) do with the stream returned by (open :direction
:probe ...) except observe that it is not null and later use it as a
pathname designator. I admit I hadn't thought of using it to carry
around the element-type information for later use.
> | Do folks have particular stylistic preferences?
>
> The two functions perform very different functions. The intersection
> is actually rather uninteresting. For instance, you may supply OPEN
> with :IF-DOES-NOT-EXIST. OPEN returns a stream with a specified
> element-type that you should expect to be honored if you pass the same
> stream to a later OPEN call. (Not that this expectation is satisfied
> everywhere, but at least you can provide the argument explicitly with
> :element-type (stream-element-type <stream>).)
Hmmm. I never realized that passing a stream as a pathname designator
to OPEN *should* convey anything more than the name of the file that
the stream was associated with. I just reread the OPEN dictionary
entry and didn't see anything to suggest that; did I miss it or is it
somewhere else in the spec?
> | (Or have I missed some distinction?)
>
> I wonder if you are fully aware of the factors you chose to ignore in
> order to believe they are so similar.
Well, now I wonder too.
Erik Naggum
| I admit I hadn't thought of using it to carry around the element-type
| information for later use.
Not only that, it is useful to remember the external-format argument
to be used to open a particular file. The pathname is unable to carry
all this information around.
| I never realized that passing a stream as a pathname designator to
| OPEN *should* convey anything more than the name of the file that the
| stream was associated with. I just reread the OPEN dictionary entry
| and didn't see anything to suggest that; did I miss it or is it
| somewhere else in the spec?
No, it just falls in the category of my reasonable expectations, which
may or may not be codified or shared by others. Now I realize that I
had written my own open that effectively did
(open <stream> ... :element-type (stream-element-type <stream>)
:external-format (stream-external-format <stream>))
in addition to figuring out the direction of the stream if :direction
was not explicitly specified.
Peter Seibel
> * Peter Seibel
> | I admit I hadn't thought of using it to carry around the element-type
> | information for later use.
>
> Not only that, it is useful to remember the external-format argument
> to be used to open a particular file. The pathname is unable to carry
> all this information around.
>
> | I never realized that passing a stream as a pathname designator to
> | OPEN *should* convey anything more than the name of the file that the
> | stream was associated with. I just reread the OPEN dictionary entry
> | and didn't see anything to suggest that; did I miss it or is it
> | somewhere else in the spec?
>
> No, it just falls in the category of my reasonable expectations,
> which may or may not be codified or shared by others. Now I
> realize that I had written my own open that effectively did
>
> (open <stream> ... :element-type (stream-element-type <stream>)
> :external-format (stream-external-format <stream>))
>
> in addition to figuring out the direction of the stream if :direction
> was not explicitly specified.
So that makes good sense, given that you wrote your own OPEN--I can
see why that would be a reasonable behavior. But it seems to me that
if some implementation's CL:OPEN did that, it would be non-conforming
because the spec does say what those parameters default to and it's
not information derived from the filespec argument. That is, I claim
that this:
(let ((s (open #p"/tmp/foo.txt" :direction :probe :element-type '(unsigned-byte 8))))
(with-open-file (in (open s)) (stream-element-type in)))
ought to evaluate to CHARACTER not (UNSIGNED-BYTE 8).[1]
-Peter
[1] Of course in Allegro this gets all messed up because of their
change to OPEN to support simple-streams: the default value for
element-type is (UNSIGNED-BYTE 8) instead of CHARACTER. But even in
Allegro if the :probe stream is given some other type, say
(UNSIGNED-BYTE 16), the :input stream is still element-type
(UNSIGNED-BYTE 8)