Evaluate a closure in a subprocess?

Evaluate a closure in a subprocess?

[Klaus-Dieter Bauer]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1489 bytes --]

Re: Evaluate a closure in a subprocess?

[Stefan Monnier]

> 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).

Not only it's not future proof, but it's neither present-proof nor
past-proof since it already breaks in Emacs-24.1 if you byte-compile
the code.

> 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.

As long as the free variables of your closure have values which are
linearizable/marshallable then I think it should work, yes.  Note that
it should work better if you byte-compile your code since in that case
the closure will only include the free variables, whereas if your code
is interpreted the closure includes the whole lexical environment (which
may hence include variables that aren't actually used by your closure
yet whose value is either unmarshallable or very large).
Of course, since closures include (byte-)code, the other side needs to
understand that same (byte-)code.


        Stefan