[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: with-open-stream and with-open-file



    Date: Fri, 16 Oct 87 10:56:21 PDT
    From: Pavel.pa@Xerox.COM
	[deleted]
    Surely I'm misunderstanding you.  Why use the above form instead of
    simply `constructor'?  
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))
	    ...process-options...
	    (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
    your intent?
Yes.

    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
   cleanup.
 - 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.