On Tue, Aug 19, 2014 at 01:19:35PM -0400, John Cowan wrote: > Peter Bex scripsit: > > > Note that this does _not_ imply we should implement things that we > > don't already have, just move the things we do have under the names > > defined by R7RS. If we have something that's close to R7RS but not > > identical, we may decide to tweak it to match R7RS. Except for > > R7RS-style parameters ;) > > +1, but what's wrong with R7RS parameters? They are entirely compatible > with Chicken parameters AFAICT; the ability to mutate a parameter isn't > present in R7RS, but R7RS documents that the effect of (p x) where > p is a parameter is implementation-defined.
As I understood Felix's comments at the time, R7RS parameterize behaves differently with threads. However, after re-reading the relevant section it appears that CHICKEN's parameterize is indeed perfectly compatible with R7RS. Maybe Felix can explain the nuances I missed again. It's unfortunate that R7RS mentioned threads here at all: it doesn't say anything about threads *anywhere* else, in the whole document. It should've left this undefined: threads are out of scope for the document. > In Chicken, child threads capture the current value in the parent > when they are created, and after that the parameters in the threads > are independent. Leaving mutation explicitly implementation-dependent > avoids having to resolve this issue in portable code. The way parameters and threads work right now is perfect for CHICKEN, and there are various libraries that make use of this (most notably Spiffy, which relies on it heavily). Cheers, Peter -- http://www.more-magic.net _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
