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.

Source for ticket #35

cc

changetime

2010-11-15 09:51:41

component

WG1 - Core

description

Do we provide any values with dynamic scope,
such as SRFI-39 parameters?  How do they
interact with call/cc and/or threads?

id

keywords

milestone

owner

alexshinn

priority

major

reporter

alexshinn

resolution

duplicate

severity

status

closed

summary

dynamically scoped values

time

2010-02-23 17:09:13

type

defect

Changes

Change at time 2010-11-15 09:51:41

author

alexshinn

field

comment

newvalue

Duplicate of #69.

oldvalue

raw-time

1289785901000000

ticket

time

2010-11-15 09:51:41

Change at time 2010-11-15 09:51:41

author

alexshinn

field

milestone

newvalue

oldvalue

raw-time

1289785901000000

ticket

time

2010-11-15 09:51:41

Change at time 2010-11-15 09:51:41

author

alexshinn

field

resolution

newvalue

duplicate

oldvalue

raw-time

1289785901000000

ticket

time

2010-11-15 09:51:41

Change at time 2010-11-15 09:51:41

author

alexshinn

field

status

newvalue

closed

oldvalue

new

raw-time

1289785901000000

ticket

time

2010-11-15 09:51:41

Change at time 2010-03-01 10:45:47

author

cowan

field

comment

newvalue

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.

oldvalue

raw-time

1267411547000000

ticket

time

2010-03-01 10:45:47