Re: Some improvements for cl-flet

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I'm not going to answer for Po Lu, but I'll only mention something not yet
  > said about this form, which is that it is so important to the Common Lisp
  > language that it's not even a macro, it's one of the fundamental "special
  > forms" of the language (added sometime in 1988, it seems).

That was after my involvement in Common Lisp, so I never heard of it.
However, I think I see why it is a special form rather than a macro.

A macro expands one Lisp expression into another Lisp expression.
Without some way to make a "variable" stand for magic slots, there was
no way to write a macro that would create such variables.  (What would
that macro expand into?)  So they had to make it a built-in execution
feature.

This doesn't mean it is a good feature to have in a language.  It
messes up the language semantics.  In Emacs we have some variables
with magical effects on editing, but as far as Lisp semantics is
concerned they are only variables.

The definition of `cl-symbol-macro' calls `macroexpand'.  The reason
that method is _possible_ is because the magic "variable" is defined
only inside one expression.  But it is still kludgy.

Worse, it operates by putting advice on `macroexpand'.

Code inside Emacs should _never_ create advice!  Never, ever!  Putting
advice on a function makes that function mysterious.  It obfuscates
debugging that function, because it function does something other than
what its code says.

If we are going to have `cl-symbol-macro', it should be rewritten to
bind a hook which `macroexpand' explicitly runs.  The hook does the
same work as the advice, but the call to run the hook is visible in
the code -- not mysterious magic.

>From node Advising Named Functions in the Emacs Lisp Reference Manual:

      @code{advice-add} can be useful for altering the behavior of existing 
calls
    to an existing function without having to redefine the whole function.
    However, it can be a source of bugs, since existing callers to the function 
may
    assume the old behavior, and work incorrectly when the behavior is changed 
by
    advice.  Advice can also cause confusion in debugging, if the person doing 
the
    debugging does not notice or remember that the function has been modified
    by advice.

      For these reasons, advice should be reserved for the cases where you
    cannot modify a function's behavior in any other way.  If it is
    possible to do the same thing via a hook, that is preferable
    (@pxref{Hooks}).  If you simply want to change what a particular key
    does, it may be better to write a new command, and remap the old
    command's key bindings to the new one (@pxref{Remapping Commands}).

      If you are writing code for release, for others to use, try to avoid
    including advice in it.  If the function you want to advise has no
    hook to do the job, please talk with the Emacs developers about adding
    a suitable hook.  Especially, Emacs's own source files should not put
    advice on functions in Emacs.  (There are currently a few exceptions
    to this convention, but we aim to correct them.)  It is generally
    cleaner to create a new hook in @code{foo}, and make @code{bar} use
    the hook, than to have @code{bar} put advice in @code{foo}.

It looks like this is not visible enough.  Perhaps we should put this in
the top node for advising, and make more links to it.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)