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?)
Peter Seibel <pe...@javamonkey.com> writes: > 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.
Peter Seibel wrote: > 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).
> > 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).
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.
Peter Seibel <pe...@javamonkey.com> writes: > 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! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
* 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.
| 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.
Erik Naggum <e...@naggum.no> writes: > * 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.
* 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
Erik Naggum <e...@naggum.no> writes: > * 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
> 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:
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)
