+\1f
+File: xemacs-faq.info, Node: Q5.1.5, Next: Q5.1.6, Prev: Q5.1.4, Up: Miscellaneous
+
+Q5.1.5: What is the recommended use of `setq'?
+----------------------------------------------
+
+ * Global variables
+
+ You will typically `defvar' your global variable to a default
+ value, and use `setq' to set it later.
+
+ It is never a good practice to `setq' user variables (like
+ `case-fold-search', etc.), as it ignores the user's choice
+ unconditionally. Note that `defvar' doesn't change the value of a
+ variable if it was bound previously. If you wish to change a
+ user-variable temporarily, use `let':
+
+ (let ((case-fold-search nil))
+ ... ; code with searches that must be case-sensitive
+ ...)
+
+ You will notice the user-variables by their docstrings beginning
+ with an asterisk (a convention).
+
+ * Local variables
+
+ Bind them with `let', which will unbind them (or restore their
+ previous value, if they were bound) after exiting from the `let'
+ form. Change the value of local variables with `setq' or whatever
+ you like (e.g. `incf', `setf' and such). The `let' form can even
+ return one of its local variables.
+
+ Typical usage:
+
+ ;; iterate through the elements of the list returned by
+ ;; `hairy-function-that-returns-list'
+ (let ((l (hairy-function-that-returns-list)))
+ (while l
+ ... do something with (car l) ...
+ (setq l (cdr l))))
+
+ Another typical usage includes building a value simply to work
+ with it.
+
+ ;; Build the mode keymap out of the key-translation-alist
+ (let ((inbox (file-truename (expand-file-name box)))
+ (i 0))
+ ... code dealing with inbox ...
+ inbox)
+
+ This piece of code uses the local variable `inbox', which becomes
+ unbound (or regains old value) after exiting the form. The form
+ also returns the value of `inbox', which can be reused, for
+ instance:
+
+ (setq foo-processed-inbox
+ (let .....))
+
+\1f
+File: xemacs-faq.info, Node: Q5.1.6, Next: Q5.1.7, Prev: Q5.1.5, Up: Miscellaneous
+
+Q5.1.6: What is the typical misuse of `setq' ?
+----------------------------------------------
+
+ A typical misuse is probably `setq'ing a variable that was meant to
+be local. Such a variable will remain bound forever, never to be
+garbage-collected. For example, the code doing:
+
+ (defun my-function (whatever)
+ (setq a nil)
+ ... build a large list ...
+ ... and exit ...)
+
+ does a bad thing, as `a' will keep consuming memory, never to be
+unbound. The correct thing is to do it like this:
+
+ (defun my-function (whatever)
+ (let (a) ; default initialization is to nil
+ ... build a large list ...
+ ... and exit, unbinding `a' in the process ...)
+
+ Not only is this prettier syntactically, but it makes it possible for
+Emacs to garbage-collect the objects which `a' used to reference.
+
+ Note that even global variables should not be `setq'ed without
+`defvar'ing them first, because the byte-compiler issues warnings. The
+reason for the warning is the following:
+
+ (defun flurgoze nil) ; ok, global internal variable
+ ...
+
+ (setq flurghoze t) ; ops! a typo, but semantically correct.
+ ; however, the byte-compiler warns.
+
+ While compiling toplevel forms:
+ ** assignment to free variable flurghoze
+
+\1f
+File: xemacs-faq.info, Node: Q5.1.7, Next: Q5.1.8, Prev: Q5.1.6, Up: Miscellaneous
+
+Q5.1.7: I like the `do' form of cl, does it slow things down?
+-------------------------------------------------------------
+
+ It shouldn't. Here is what Dave Gillespie has to say about cl.el
+performance:
+
+ Many of the advanced features of this package, such as `defun*',
+ `loop', and `setf', are implemented as Lisp macros. In
+ byte-compiled code, these complex notations will be expanded into
+ equivalent Lisp code which is simple and efficient. For example,
+ the forms
+
+ (incf i n)
+ (push x (car p))
+
+ are expanded at compile-time to the Lisp forms
+
+ (setq i (+ i n))
+ (setcar p (cons x (car p)))
+
+ which are the most efficient ways of doing these respective
+ operations in Lisp. Thus, there is no performance penalty for
+ using the more readable `incf' and `push' forms in your compiled
+ code.
+
+ _Interpreted_ code, on the other hand, must expand these macros
+ every time they are executed. For this reason it is strongly
+ recommended that code making heavy use of macros be compiled. (The
+ features labelled "Special Form" instead of "Function" in this
+ manual are macros.) A loop using `incf' a hundred times will
+ execute considerably faster if compiled, and will also
+ garbage-collect less because the macro expansion will not have to
+ be generated, used, and thrown away a hundred times.
+
+ You can find out how a macro expands by using the `cl-prettyexpand'
+ function.
+
+\1f
+File: xemacs-faq.info, Node: Q5.1.8, Next: Q5.1.9, Prev: Q5.1.7, Up: Miscellaneous
+
+Q5.1.8: I like recursion, does it slow things down?
+---------------------------------------------------
+
+ Yes. Emacs byte-compiler cannot do much to optimize recursion. But
+think well whether this is a real concern in Emacs. Much of the Emacs
+slowness comes from internal mechanisms such as redisplay, or from the
+fact that it is an interpreter.
+
+ Please try not to make your code much uglier to gain a very small
+speed gain. It's not usually worth it.
+