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

Reply via email to