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. The reason WG1 did that is so as not to have to worry about whether mutation in a parent thread, either before or after a child thread is created or started, affects the parameter value in the child, and per contra whether mutation in the child affects the parent. Different Schemes behave differently in these respects, as SRFI 39 documents. 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. > "proper cleanups" are very dangerous. However, if done right, they can > make life better. Emphatic +1. -- John Cowan http://www.ccil.org/~cowan co...@ccil.org And they pack their lyrics till they're so damn dense You could put 'em in your yard and you could use 'em for a fence. --Alan Chapman, "Everybody Wants to Be Sondheim" _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers