This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.
Do we provide any values with dynamic scope,
such as SRFI-39 parameters? How do they
interact with call/cc and/or threads?
cowan
2010-03-01 10:45:47
SRFI 39 parameters are supported (according to the documentation) by PLT, Gauche, Gambit, Chicken, Guile, Kawa, SISC, Chibi, IronScheme, Ikarus, Larceny, Mosh, STKlos.
MIT, Bigloo, Scheme48/scsh, Chez, SCM, Ypsilon, s7, SigScheme, SXM, Pocket, stk, Sizzle, Scheme 9 do not support them.
Call/cc should not interact with dynamic parameters.
I don't believe that WG1 should standardize threads, so I don't think we have to decide about them. The SRFI notes three possible ways to interact: reset all parameters in each new thread, copy the current state of all parameters to new threads, share parameters with new threads. In all cases, parameters in new threads are in the ground (un-parameterized) state.
As to why we should standardize them at all, it's because if portable code wants to expose parameters, it will have to provide the parameter procedures itself in a thread-unsafe way, which will combine badly on threaded systems with any existing parameter procedures.
SRFI 39 parameters are supported (according to the documentation) by PLT, Gauche, Gambit, Chicken, Guile, Kawa, SISC, Chibi, IronScheme, Ikarus, Larceny, Mosh, STKlos.
MIT, Bigloo, Scheme48/scsh, Chez, SCM, Ypsilon, s7, SigScheme, SXM, Pocket, stk, Sizzle, Scheme 9 do not support them.
Call/cc should not interact with dynamic parameters.
I don't believe that WG1 should standardize threads, so I don't think we have to decide about them. The SRFI notes three possible ways to interact: reset all parameters in each new thread, copy the current state of all parameters to new threads, share parameters with new threads. In all cases, parameters in new threads are in the ground (un-parameterized) state.
As to why we should standardize them at all, it's because if portable code wants to expose parameters, it will have to provide the parameter procedures itself in a thread-unsafe way, which will combine badly on threaded systems with any existing parameter procedures.