I'm implementing srfi-226 delay/force semantics in Gauche natively, and one test breaks---srfi-155. The reference implementation of srfi-155 builds on top of R7RS semantics delay. So it is logical that changing built-in delay/force semantics affects it.
I don't think it affects srfi-226; Just want to record the experience here. On Sat, Mar 11, 2023 at 9:29 AM Shiro Kawai <shiro.ka...@gmail.com> wrote: > Gauche has been mutexing realization of a promise, but srfi-226 is the > right thing; evaluation of the body may communicate to another thread that > may take the value of the promise. Current Gauche deadlocks in that case. > > By the way, in the reference implementation, 'force' has this code: > > (if (promise-done? p) > ((promise-thunk p)) > (call-with-immediate-continuation-mark ....)) > > And: > > (promise-lock! p) > ... > (promise-done?-set! p (promise-done? q)) > (promise-thunk-set! p (promise-thunk q))) > ... > (promise-unlock! p) > > First I thought you need to lock promise to check promise-done? and > retrieve promise-thunk, otherwise you may read the old value of > promise-thunk and reevaluate the body. However, it is allowed that the > body is evaluated multiple times, it's ok. Am I understanding it right? > > > > > > > > > > > On Sat, Mar 11, 2023 at 3:02 AM Marc Nieper-Wißkirchen < > marc.nie...@gmail.com> wrote: > >> Am Sa., 11. März 2023 um 11:11 Uhr schrieb Shiro Kawai < >> shiro.ka...@gmail.com>: >> > >> > From the srfi text, it is allowed that the delay's body to be evaluated >> by more than one thread simultaneously; only that the result of force is >> the result of the first delivered result. Am I right? >> >> Indeed. This is analogous to promises being forced while their "body" >> is evaluated, even in the same thread. >> >> > >> >
