From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Klaus-Dieter Bauer Newsgroups: gmane.emacs.devel Subject: Evaluate a closure in a subprocess? Date: Sun, 9 Aug 2015 18:06:18 +0200 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0122af2a647d66051ce30edf X-Trace: ger.gmane.org 1439136425 18802 80.91.229.3 (9 Aug 2015 16:07:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Aug 2015 16:07:05 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 09 18:06:57 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZOT7g-0000Vr-Lj for ged-emacs-devel@m.gmane.org; Sun, 09 Aug 2015 18:06:56 +0200 Original-Received: from localhost ([::1]:55684 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOT7f-0000r3-ON for ged-emacs-devel@m.gmane.org; Sun, 09 Aug 2015 12:06:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57570) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOT7b-0000qw-7g for emacs-devel@gnu.org; Sun, 09 Aug 2015 12:06:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZOT7a-0002Zd-8Z for emacs-devel@gnu.org; Sun, 09 Aug 2015 12:06:51 -0400 Original-Received: from mail-lb0-x231.google.com ([2a00:1450:4010:c04::231]:34478) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOT7Z-0002Z4-Vb for emacs-devel@gnu.org; Sun, 09 Aug 2015 12:06:50 -0400 Original-Received: by lbbtg9 with SMTP id tg9so45653273lbb.1 for ; Sun, 09 Aug 2015 09:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=xCmHsgwpV9kkoNRJXs70xwcwDHSYeEZhOUsDZwR/vos=; b=YX48xZ1BEG+hVa2XN3gqXCpKsRu3zxKA1sD5c32p3bK2zs+A3K0/MRlIN3fn8HGjL5 i9tL3WM20wORVC6hZ0sRqRqiOrPin0jDjXiRd7mO6+9HOSedwh885dzCsOx+joIdMKJO 1/IYkLgzVyIFD4uvzdt17DSwGcx9yKn1IogdePJAe4ghdzXq/oWI7XiRFA5MHqDdHRIy imLpif5wMmkXuKQdqKkcpjrjmInADIOD0f8yuvbDuCncVzgOweaJtKtMc9MYiTJUkZat nEgICGc3J0T+MVBiTBzuga+dDVS6e797GJEj9p++38vUQkbnBcGDaQw91QZtiE+btdbm nmtA== X-Received: by 10.112.154.106 with SMTP id vn10mr6591486lbb.38.1439136408171; Sun, 09 Aug 2015 09:06:48 -0700 (PDT) Original-Received: by 10.114.201.33 with HTTP; Sun, 9 Aug 2015 09:06:18 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::231 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:188646 Archived-At: --089e0122af2a647d66051ce30edf Content-Type: text/plain; charset=UTF-8 Hello! Currently `lambda' forms evaluate to a `closure' form in lexical environments, where the first element after the 'closure symbol represents the lexical environment. The documentation clearly states that this form shouldn't be relied on, so e.g. extracting the lexical environment from the closure form is not future-proof (i.e. using (cadr (lambda ())) as an equivalent to python's locals() function). However, the current implementation also allows passing a closure, or even its byte-code representation, as a string to a different emacs process and evaluate it there, preserving the values of the captured lexical environment, e.g. (call-process "emacs" nil (current-buffer) nil "--batch" "--eval" (format "(print (funcall (quote %S)))" (let ((lp load-path)) (lambda () lp)))) I currently use a similar construct for compiling emacs lisp files in a clean emacs session (since a long-running session may contain artifacts that mask or cause errors). So I was wondering if this is an intended behaviour or also a side-effect of the current implementation that may change at any time. regards, Klaus --089e0122af2a647d66051ce30edf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello!

Currently `lambda' forms eva= luate to a `closure' form in lexical environments, where the first elem= ent after the 'closure symbol represents the lexical environment.=C2=A0=

The documentation clearly states that this form s= houldn't be relied on, so e.g. extracting the lexical environment from = the closure form is not future-proof (i.e. using (cadr (lambda ())) as an e= quivalent to python's locals() function).=C2=A0

However, the current implementation also allows passing a closure, or eve= n its byte-code representation, as a string to a different emacs process an= d evaluate it there, preserving the values of the captured lexical environm= ent, e.g.=C2=A0

=C2=A0 =C2=A0 (call-proc= ess "emacs" nil (current-buffer) nil "--batch" "--= eval"=C2=A0
=C2=A0 =C2=A0 =C2=A0 (format "(print (funca= ll (quote %S)))"=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (let ((lp= load-path))=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (lambda () = lp))))

I currently use a similar const= ruct for compiling emacs lisp files in a clean emacs session (since a long-= running session may contain artifacts that mask or cause errors).=C2=A0

So I was wondering if this is an intended behaviour o= r also a side-effect of the current implementation that may change at any t= ime.=C2=A0


regards, Klaus
--089e0122af2a647d66051ce30edf--