emacs-devel
[Top][All Lists]
Advanced

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

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r104642: * src/process.c (Fset_pr


From: Stephen J. Turnbull
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r104642: * src/process.c (Fset_process_buffer): Clarify return value in docstring.
Date: Tue, 21 Jun 2011 13:10:28 +0900

Stefan Monnier writes:
 > >> Actually, I generally prefer not to document the accidental return value
 > >> of side-effecting functions.
 > 
 > > What's accidental in
 > >   return buffer;
 > > ?
 > 
 > That the author could just as well have written "return Qnil;" or
 > various other options.

Well, since the DEFUN macro basically requires a return value, and all
functions defined in Lisp do return something, you probably ought to
say that a function should return nil unless there's an obviously good
value to return.

 > I can't find a single example of Elisp code in Emacs that does not
 > ignore the return value of set-process-buffer (and that's a good thing).

Not necessarily a good thing in Elisp.  Like it or not, Elisp has
never made a strong distinction between functions that return values
and functions that have side effects.

While you may prefer the style

    (let ((buf (get-buffer-create "buffer for process")))
      (set-process-buffer proc buf)
      (do-buffing buf))

in Elisp it's common enough to see the style

      (do-buffing
       (set-process-buffer proc
                           (get-buffer-create "buffer for process")))

and I don't really see anything wrong with that in Elisp.

Of course as a matter of design, in many cases it's preferable to
return nil now, and think about what a useful return value might be
after we see use cases for the function.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]