From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.help Subject: Re: How do I pass a variable defined in a wrapping let, to a lambda? Date: Sat, 12 Mar 2022 09:40:22 +0300 Message-ID: References: <87k0d03vaw.fsf@ericabrahamsen.net> <8735joc5of.fsf@web.de> <87r177rjzn.fsf@zoho.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20630"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.2.0 (2022-02-12) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 12 08:01:38 2022 Return-path: Envelope-to: geh-help-gnu-emacs@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 1nSvkv-0005E1-Qn for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 12 Mar 2022 08:01:37 +0100 Original-Received: from localhost ([::1]:60234 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nSvku-0001Jr-0j for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 12 Mar 2022 02:01:36 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60362) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nSvkH-0001Jd-4g for help-gnu-emacs@gnu.org; Sat, 12 Mar 2022 02:00:57 -0500 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:51493) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nSvkF-0006Dh-7W for help-gnu-emacs@gnu.org; Sat, 12 Mar 2022 02:00:56 -0500 Original-Received: from localhost ([::ffff:102.87.160.206]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000003FE1A.00000000622C4524.00007F07; Sat, 12 Mar 2022 00:00:52 -0700 Mail-Followup-To: help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <87r177rjzn.fsf@zoho.eu> Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:136479 Archived-At: * Emanuel Berg via Users list for the GNU Emacs text editor [2022-03-12 05:41]: > Michael Heerdegen wrote: > > > you may want to find out what evaluating lexical-binding in > > the buffer with lexical-binding -> nil gives you. > > > > Second: (AFAIK...) be sure to reeval `steinars-test' with > > lexical-binding -> nil. `steinars-test' defined using the > > lexical binding dialect will return a closure even when > > called in the dynamcially binding dialect. > > This is an example of why I think there should be three `let': > > * "let" that is static/lexical except for already-defined > dynamic/special variables (i.e., what `let' is already under > static/lexical scope, so won't break any code to change. > well, there wouldn't be any change except static/lexical > would be default everywhere) > > * "dlet" that is always dynamic/special New `dlet' is this and it broke my programs because somebody removed `let*' inside. I don't think that person who changed it every used `dlet' in their own programs. Reason is semantics, "dlet" uses "let*" so they changed it, but did not provide "dlet*" (though is easy to adapt it). new `dlet': (defmacro dlet (binders &rest body) "Like `let' but using dynamic scoping." (declare (indent 1) (debug let)) ;; (defvar FOO) only affects the current scope, but in order for ;; this not to affect code after the main `let' we need to create a new scope, ;; which is what the surrounding `let' is for. ;; FIXME: (let () ...) currently doesn't actually create a new scope, ;; which is why we use (let (_) ...). `(let (_) ,@(mapcar (lambda (binder) `(defvar ,(if (consp binder) (car binder) binder))) binders) (let ,binders ,@body))) so I have just changed it back to what it was and use it with my own prefix as `rcd-dlet' -- that way there is no need for quarrel. (defmacro rcd-dlet (binders &rest body) "Like `let*' but using dynamic scoping." (declare (indent 1) (debug let)) ;; (defvar FOO) only affects the current scope, but in order for ;; this not to affect code after the main `let' we need to create a new scope, ;; which is what the surrounding `let' is for. ;; FIXME: (let () ...) currently doesn't actually create a new scope, ;; which is why we use (let (_) ...). `(let (_) ,@(mapcar (lambda (binder) `(defvar ,(if (consp binder) (car binder) binder))) binders) (let* ,binders ,@body))) I find `dlet', rather `rcd-dlet' very useful in interpolation of variables and templates that come from third sources, thus not coming from the Emacs Lisp file itself. Some insights: (rcd-dlet ((wrs::template (gethash "templates_content" wrs::template)) ;; now wrs::template is visible inside of ;; wrs::template, sounds funny (open-graph-type "Article") ;; now "open-graph-type" variable is accessible ;; for use or interpolation within wrs::template scripts (wrs::html (rcd-template-eval wrs::template '("⟦" "⟧") wrs::variables)) ;; now wrs::template is interpolating various ;; wrs::variables, expanding them inside of the ;; template as otherwise they would not be visible ;; rcd-dlet as only rcd-dlet breaks out of lexical binding (wrs::local-file (wrs-page-url page-id t)) (wrs::local-dir (file-name-directory wrs::local-file))) (make-directory wrs::local-dir t) (string-to-file-force wrs::html wrs::local-file))))) -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/