[Openmcl-devel] Thread-local bindings

[martin]

Hello All

I am confused about the semantics of thread-local bindings when using process-run-function. 
CCL version: Clozure Common Lisp Version 1.12-dev (v1.12-dev.4-3-gdd5622e9) DarwinX8664

Suppose that the variable foo is not globally bound:

? foo
> Error: Unbound variable: FOO

Consider the following form:

(process-run-function :process1 
  #'(lambda ()
      (let ((foo 2))
        (flet ((bar () (print foo) :return-me-from-foo))
          (bar)
          (process-run-function :process2 #'bar)
          :return-me-from-lambda))))

The result is to print 2 twice:

2 
2 

Neither keyword return value appears, nor should they — I put them in the code to disambiguate printing from the value returned by print.

Now bind foo at top level.

? (defvar foo 3)
FOO

Execute the form again, to get these to print results:

2 
3 

My confusion: 
The second result (print 2 & 3) demonstrates my understanding of thread-local bindings.
The first result (print 2 & 2) seems wrong — why didn’t Lisp complain that foo was unbound in the call to bar within :process2 ?

My confusion gets worse — restart Lisp, so that foo is not globally bound, and do the same tests with the following form, to see it print 4 & 4.

(let ((foo 4))
  (process-run-function :process1 
    #'(lambda ()
        (flet ((bar () (print foo) :return-me-from-foo))
          (bar)
          (process-run-function :process2 #'bar)
          :return-me-from-lambda))))

4 
4 

And now globally bind foo:

? (defvar foo 5)
FOO

The form now prints 5 & 5 .

5 
5

Help! What’s the rule?!?

Furthermore, I take it that stack-local bindings apply to variables only, not functions.
To test this, I gave bar a global definition:

(defun bar () (print 27))

But this did not change the above results; in other words, the local definition was used in both threads.

All consolation gratefully accepted,
Martin






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20190614/cc4f6d2d/attachment.htm>