From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: tomas@tuxteam.de Newsgroups: gmane.emacs.help Subject: Re: [SOLVED with `eval']: Why I cannot use this variable in macro call from function? Date: Wed, 9 Jun 2021 18:41:12 +0200 Message-ID: <20210609164112.GB16067@tuxteam.de> References: <20210609060959.GA21706@tuxteam.de> <20210609065129.GB21706@tuxteam.de> <20210609073928.GC21706@tuxteam.de> <20210609085406.GH21706@tuxteam.de> <20210609113353.GB4155@tuxteam.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="raC6veAxrt5nqIoY" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18134"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.5.21 (2010-09-15) To: Help GNU Emacs Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 09 18:41:51 2021 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 1lr1H4-0004Wt-Kv for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 09 Jun 2021 18:41:50 +0200 Original-Received: from localhost ([::1]:36734 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lr1H3-0007TI-La for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 09 Jun 2021 12:41:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39848) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lr1GX-0007Qp-9L for help-gnu-emacs@gnu.org; Wed, 09 Jun 2021 12:41:17 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]:41103) by eggs.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.90_1) (envelope-from ) id 1lr1GU-0007hO-Lj for help-gnu-emacs@gnu.org; Wed, 09 Jun 2021 12:41:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=GDcuOaCLpyLHzBsBjiLWofTcYR0qb110d9wl9je2X+4=; b=DDxAn8UM46c5NHGuYHzrnIo/L6QQqQqKFVWXmCVpXRkZ9vYZZtLyfc9KqCexrMOxNwnhlZvRi+2xzwLwPpUdJgCM1DfGL7E5txvtV8Jv+8kNBQFBjNwsefxTYgbc/GBxqcMR9mrwchwELUC9BvZg7qn4W464J/qUMLD8AubhmwuTTUlt4VE47U/EF3sQzwjea+jA8UKthrtRfaYo6BqgCp8XiNyiyI9lL2pfIoVnHngwMy7oYP99QPjg8xIPx/W3hi0jR7Bx7LvhyaDUtZknmW3mZrk8AsjOx7+XkQl6wMlXmqoPBT4bUH8u6wraQUg0FIqU1aTs4qi1CJC35K356Q==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.80) (envelope-from ) id 1lr1GS-00054g-4F for help-gnu-emacs@gnu.org; Wed, 09 Jun 2021 18:41:12 +0200 Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=5.199.139.25; envelope-from=tomas@tuxteam.de; helo=mail.tuxteam.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 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:130678 Archived-At: --raC6veAxrt5nqIoY Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 09, 2021 at 05:39:25PM +0300, Jean Louis wrote: > ;; -*- lexical-binding: t; -*- > * tomas@tuxteam.de [2021-06-09 14:35]: > > On Wed, Jun 09, 2021 at 01:56:45PM +0300, Jean Louis wrote: > > > * tomas@tuxteam.de [2021-06-09 11:54]: > > > > On Wed, Jun 09, 2021 at 11:22:38AM +0300, Jean Louis wrote: > > > > > * tomas@tuxteam.de [2021-06-09 10:40]: > > > > > > You snipped the (for me) interesting part: did you notice how > > > > > > `eval' jumps over the local declaration? > > > > >=20 > > > > > Do you mean variables within `let'? > > > >=20 > > > > Yes, it doesn't see them :) > > >=20 > > > Maybe in theory it does not see, but in reality it does see it as > > > `list' is evaluated before `eval', so the interned `rcd-symbol' and > > > variable `description' they get evaluated before `eval'. >=20 > > That sentence doesn't make any sense to me. It does or it doesn't. >=20 > Well, I get confused too, you said that it does not see, but it is > obvious that it does see. >=20 > > I propose to you the next experiment: > >=20 > > * experiment 3 > >=20 > > (let () > > (let ((x 42)) > > (eval '(progn (setq x 43) (message "in eval: x is %S" x))) > > (message "inner let: x is %S" x)) > > (message "outer let: x is %S" x)) > >=20 > > (you might have to switch to the *Messages* buffer to see all three > > messages). >=20 > The outer scope does not see the inner scope. >=20 > Then the buffer *Backtrace* jumps up: >=20 > Debugger entered--Lisp error: (void-variable x) > (message "outer let: x is %S" x) > (let nil (let ((x 42)) (eval '(progn (setq x 43) (message "in eval: x i= s %S" x))) (message "inner let: x is %S" x)) (message "outer let: x is %S" = x)) > eval((let nil (let ((x 42)) (eval '(progn (setq x 43) (message "in eval= : x is %S" x))) (message "inner let: x is %S" x)) (message "outer let: x is= %S" x)) nil) > elisp--eval-last-sexp(nil) > eval-last-sexp(nil) > funcall-interactively(eval-last-sexp nil) > call-interactively(eval-last-sexp nil nil) > command-execute(eval-last-sexp) Oh, that is interesting. For me (this is copied off the *Messages* buffer; I started Emacs anew to make sure no global definition of x lingers around; to make extra sure, I just eval'ed x before: it throws the expected void-variable x): in eval: x is 43 inner let: x is 42 outer let: x is 43 "outer let: x is 43" This is what I actually expect: the setq whithin the eval does set x's global (or buffer-local, if there is one) value. It doesn't touch the lexical value, because it doesn't know about it. > > What are the results? Do they correspond to your expectations? If > > not, why not? >=20 > I did not have any expectations for that piece of code and that > one does not generate new global variables to return the symbol > for history, which is what I need, and what is solved with `eval' > nicely. >=20 > Look here: >=20 > (let ((x 42)) > (eval (list 'progn (setq x 43) (message "in eval: x is %S" x)))) =E2=87= =92 "in eval: x is 43" It seems you have fun generating intentionally obfuscated code. Eval is a function, so its argument is evaluated. Let's see... (list ; a function 'progn ; (quote progn) evaluates to the symbol progn (setq x 43) ; evaluates to 43 SIDE EFFECT: set x to 43 at some global/b= uffer-local level (message "...") ; evaluates to "..." SIDE EFFECT print "..." to *Messag= es* What eval "sees" at the end is (eval '(progn 43 "in eval: x is 43")) which evaluates to "in eval: x is 43". On the way to there, two side effects happened. The symbol x was bound to 4= 3 in some (global or buffer-local) symbol table (obarray), probably "before" (message= ...) happens (I've assumed so when substituting-in the x there), and something g= ot printed to *Messages*. Go look there: you'll probably find two copies of "in eval: x is 43". The one is the side effect, the other the p from the RE= PL. > that obviously does work nicely as the list gets evaluated before eval > receives it. At least I assume it is so, according to learning about > the LISP in general. If it works nicely, we're all in agreement. I'll have to stop here. Other things demand my attention, and I just can't keep up with your bandwidth. So happy hacking! Cheers - t --raC6veAxrt5nqIoY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAmDA7ygACgkQBcgs9XrR2ka/YQCfQciQrW1WtRkFOQAqqeiVP5ia /0IAn0TFm0KlUMMOFzl0+26endGBHrKq =HdZ9 -----END PGP SIGNATURE----- --raC6veAxrt5nqIoY--