chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] CR #1142 and upcoming changes


From: John Cowan
Subject: Re: [Chicken-hackers] CR #1142 and upcoming changes
Date: Tue, 19 Aug 2014 13:19:35 -0400
User-agent: Mutt/1.5.20 (2009-06-14)

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        address@hidden
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"



reply via email to

[Prev in Thread] Current Thread [Next in Thread]