Am Fr., 24. Apr. 2020 um 14:28 Uhr schrieb Marc Feeley
<xxxxxx@iro.umontreal.ca>:

[...]

> > It probably depends on what would be used more, the (b) semantics or
> > the (c) semantics. If the (b) semantics are at least not incorrect for
> > most use cases, there's at least a way through the box thing to get to
> > the (c) type of semantics.
>
> Let me give you a real situation where the c semantics is superior and can’t be emulated with the b semantics.
>
> Say you want to debug a program remotely, so from your program’s main thread you start a thread that implements a REPL through a network connection.  The following code could be used with Gambit, but it should be easy to adapt to other Scheme’s with threads and networking:
>
>  ;; remote-repl.scm
>
>  (define (remote-repl addr)
>    (let ((conn (open-tcp-client addr)))
>      (let loop ()
>        (display "\n> " conn)
>        (force-output conn)
>        (write (eval (read conn)) conn)
>        (loop))))
>
>  (thread-start!
>   (make-thread
>    (lambda ()
>      (remote-repl "localhost:7000"))))
>
> In another terminal you run “nc -l 7000” to listen for the connection.  Now in this terminal you can inspect through this REPL what is happening in your program.
>
> If your program’s main thread has an issue because its binding for the current-directory parameter is not /tmp as it should be, then you can simply enter (current-directory "/tmp") in the remote REPL.  It is that simple because the main thread and the REPL thread share the same parameter cells.  With the b semantics you can’t implement this because current-directory is a predefined parameter and you can’t wrap it in a “box” to get the sharing semantics (more generally semantics b doesn’t scale because even if you could easily add the “box” to this parameter, you would also need to change all the places that access the current-directory in all your code and libraries, some of which are part of the runtime system that you can’t change).
>
> My point is essentially that you shouldn’t make parameter assignment a sort of second class citizen when using threads.

That's a very convincing point. So Racket did one thing right by
introducing THREAD-CELLs, which abstract thread-local storage, and did
one thing wrong by making parameter objects using thread cells
implicitly and automatically.

So if we go with the (c) semantics, it would be nice if the interface
to the parameter objects of SRFI 39 is extended in a way to make it
possible to define MAKE-THREAD-PARAMETER (the "Racket" parameter
model) in terms of MAKE-PARAMETER and MAKE-THREAD-CELL,
THREAD-CELL-REF, THREAD-CELL-SET!.  For that, it seems that parameter
objects need two more "methods", one that is used when a value is
retrieved and one that is used when a parameter value is to be set.

Marc