[slime-devel] Re: *read-default-float-format* with C-c C-k, , load-system, etc.

[Dirk Gerrits]

Helmut Eller <e9626484 at stud3.tuwien.ac.at> writes:

> Dirk Gerrits <dirk at dirkgerrits.com> writes:
>
>> I'll try this out again soon.  If the thread tree is really as you
>> describe, and ,load-system is done in the SCBL REPL thread, then there
>> shouldn't be a problem at all, right?
>
> Only if you do it before the other threads are created, of course.  If
> you do it afterwards, the value in the other threads remains
> unchanged.

Okay, now I'm confused.  

As I understood it, special variable /bindings/ are inherited by child
threads in SBCL.  Doing a SETQ in any of those threads should affect all
those threads unless they have created a new, local binding for that
variable with LET.

Are you saying that what I'm seeing is because SBCL threads inherit
special variable /values/ inside new, local /bindings/?  With 47 special
variables in the COMMON-LISP package alone, that can't be right, so I
must have misunderstood you.

> Not sure about Corman, but in Allegro the dynamic environment in new
> thread is initially empty.  See
> http://www.franz.com/support/documentation/7.0/doc/multiprocessing.htm#dynamic-environments-1

This describes exactly what I thought SBCL's (and Corman's) semantics to
be.  Can you explain the difference with
http://www.sbcl.org/manual/Special-Variables.html ?

> I added a new variable *default-worker-thread-bindings* instead.
> The intended use is something like 
>
>  (push (cons '*read-default-float-format* 'long-float)
>        *default-worker-thread-bindings*)
>
> Only new worker threads are affected by this variable.  To change the
> variable in the REPL you have to evaluate a setq in the REPL thread.

This seems to work like a charm.  Thanks a lot!

Kind regards,

Dirk Gerrits