Re: [Chicken-users] make-parameter, parameterize & SRFI-39

[F. Wittenberger]

Am Donnerstag, den 07.08.2008, 12:50 -0400 schrieb John Cowan:
> Jörg F. Wittenberger scripsit:
> 
> > This will print "now #f".  To my understanding (and not only mine) of
> > SRFI-39, it should print "now 42".
> 
> If you look at the third and fourth paragraphs of the Rationale section of
> SRFI-39, you'll see that the interaction between parameters and threads
> is kept undefined.  SRFI-39 is a retrospective SRFI that attempts to
> standardize the intersection of existing implementations.
[...]
> 
> There are arguments for all three parameter designs.  Ideally perhaps
> there would be an additional argument to thread-start! that would specify
> what kind of parameter sharing to do.

An additional argument to thread-start! or perhaps better to
make-parameter ?

I'd vote for the latter.

> Cloned-parameter systems will give the child all-new parameters also,
> but initialized to the current values in the parent thread. [...]
> Chicken is a cloned-parameter system.

I'm not sure about this one: to my understanding of the chicken source
code, it's not exactly what you describe as clone-parameter systems,
since the values are not initialised to the values in the parent thread,
but to the default values, that is the global values, if and only if the
parent thread did not set any parameters after the creation of the
parameters in question.  Complicated?  Yes.

Nevertheless, I need shared parameters in an existing application to
pass global configuration items around.

I) How would I best implement them?

a) global-set! 'make-parameter to a shared implementation and load a
different parameterize macro

b) provide an implementation of make-parameter, which takes an
additional parameter about the sharing method

c) provide an implementation of make-parameter, which cares for a new
slot of the current-thread, does otherwise the same as (b) and change
the thread related code

II) Wich one of (b) or (c) would probably make it into core chicken?
(Since otherwise (a) would be the cheapest one in development time; but
any other would be worth it, if only for completeness sake).

/Jörg