Peter Bex scripsit:

> 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.

There was a minority argument that parameters were easily implemented
in user code, and should therefore be left out of the small language
altogether.  It was pointed out that the naive implementation given in
the SRFI would interact badly with threads, which many Schemes actually
do provide.  It was undesirable for calling `parameterize` in one thread
to randomly affect the value seen in other threads, so we decided to
standardize parameters as a facade over existing implementations as much
as possible.

This meant supporting both Schemes like Chicken and Racket and ones like
Gambit, where mutation in one thread affects all parameters that aren't in
`parameterize` blocks.  The language you complain of was inserted to bar
implementations from having both threads and the naive implementation,
which would be seen by parameter users as broken.

> 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).

Sure.

Don't change a hair for me / Not if you care for me
Stay, little Valentine, stay!  / Each day is Valentine's Day.

-- 
John Cowan          http://www.ccil.org/~cowan        co...@ccil.org
    "Mr. Lane, if you ever wish anything that I can do, all you will have
        to do will be to send me a telegram asking and it will be done."
    "Mr. Hearst, if you ever get a telegram from me asking you to do
        anything, you can put the telegram down as a forgery."

_______________________________________________
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Reply via email to