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: Peter Bex
Subject: Re: [Chicken-hackers] CR #1142 and upcoming changes
Date: Tue, 19 Aug 2014 19:41:11 +0200
User-agent: Mutt/1.4.2.3i

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



reply via email to

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