From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Some improvements for cl-flet Date: Tue, 12 Oct 2021 18:42:56 -0400 Message-ID: References: <87bl4zqnqn.fsf@gmail.com> <87czpe4rj2.fsf@web.de> <874kaqqxe7.fsf@gmail.com> <87y281cowz.fsf@web.de> <87sfxdr2ds.fsf@gmail.com> <877demdb5w.fsf@gmail.com> <87tuhq20tp.fsf@web.de> <87czodcgby.fsf@yahoo.com> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28227"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, michael_heerdegen@web.de, nuclearspace@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: =?iso-8859-1?Q?Jo=C3=A3o_T=C3=A1vora?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 13 00:51:49 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1maQcf-0007AX-Mf for ged-emacs-devel@m.gmane-mx.org; Wed, 13 Oct 2021 00:51:49 +0200 Original-Received: from localhost ([::1]:36712 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1maQce-00013g-Oy for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Oct 2021 18:51:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37946) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1maQU5-0003uZ-90 for emacs-devel@gnu.org; Tue, 12 Oct 2021 18:42:58 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34582) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1maQU4-0007AM-80; Tue, 12 Oct 2021 18:42:56 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1maQU4-0001QQ-3N; Tue, 12 Oct 2021 18:42:56 -0400 In-Reply-To: (message from =?iso-8859-1?Q?Jo=C3=A3o_T=C3=A1vora?= on Mon, 11 Oct 2021 22:26:33 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:276845 Archived-At: [[[ 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)