[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: with-open-stream and with-open-file
- To: Pavel.pa@Xerox.COM, email@example.com
- Subject: Re: with-open-stream and with-open-file
- From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
- Date: Fri, 16 Oct 87 16:12 EDT
- In-reply-to: <871016-105629-3613@Xerox>
Date: Fri, 16 Oct 87 10:56:21 PDT
Surely I'm misunderstanding you. Why use the above form instead of
In my example, there is no reason...
It must be that you mean to do more stuff before
the prog1, perhaps to "set up" the stream and/or some other structures
concerned with it.
... and indeed this is what I typically use it for. I checked a few of
my cases, and what is >really< going on, for me, is in the internals of
constructing a stream and is something like
(defun open (pathname &rest open-options)
(with-open-stream (stream (construct-file-stream))
(shiftf stream nil)))
The idea would be to have the implicit
unwind-protect around those set-up forms and then be able to leave the
unwind-protect with the stream still open. Have I properly understood
If so, then I must say that I would find the form you describe far less
clear than the equivalent explicit unwind-protect. In general, I
dislike forms that pass information to invisible parts by the setting of
a lexical variable. The information path is just too hidden.
That's a good point which I'll have to think about. Five minutes'
reflection, clearly not enough, says:
- with-open-thing neatly packages the unwind-protect and the abort
- with-open-thing requires the programmer to remember only one form:
the with-open-thing form. This observation is quite weak; convention
would dictate that there would be a corresponding open-thing form
(e.g., with-open-serial-stream/open-serial-stream). It might be,
however, that the with-open-thing is an external symbol and
open-thing is internal.
The first observation will probably cause me to continue my current
practices, though at a higher level of awareness.
Whatever consensus we come to, the language should be clarified and
faulty implementations corrected so that the goal of writing portable
programs isn't diminished.