Re: [Chicken-users] egg announcement: remote-repl

[F. Wittenberger]

Am Dienstag, den 19.08.2008, 10:42 +0100 schrieb Alaric Snell-Pym:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> On 19 Aug 2008, at 10:27 am, Jörg F. Wittenberger wrote:
> 
> > That's what I have been able to do bevor.  That's not the aim.  I need
> > to change all timeouts for all thread which are started after the
> > change.
> 
> This boils down to an interesting question: if you have some values  
> that generally follow the 'design pattern' of a parameter - with  
> dynamically-scoped thread-local overrides and all that - how do you  
> tweak it from outside the thread?

As far as I understood the one who posted the message explaining these
three parameter designs, as far as I understood SRFI-39 until that
understanding collided with the behavior of chicken (and thus learned
that my understanding was not wrong, but incomplete) and as far as (at
least 1) other Scheme(s) understand&implement SRFI-39... the "shared"
parameter design solves the task.  Setting a parameter set's the current
binding, whatever that is.  "Parameterize" is the only thing to
introduce thread-local overwrites.  Thus outside a parameterize'd
section the current biding is the default (i.e., global) one.

Since both designs appear useful to me (I forgot about the details of
the 3rd), I'd rather support all of them for the user to choose
appropriately.

> I think this is only a legitimate thing to do in debugging; if you  
> want to do that as part of your normal use of the app, then using  
> parameters in the first place was a mistake!

Agreed.  (If you include "setting up a new host" - which boils down to
"find out why it's not working properly" under debugging.  In so far
this debugging facility is easily available from a administrators user
interface.

> Normal production configuration changes should probably be handled in  
> a server system by instructing the master thread to set new values  
> into its parameters, which *new session threads* would then inherit  
> from it, so that existing session threads keep the old values -  
> unless you want to audit your code for the consequences of a value  
> used in the session threads changing at any possible point in the  
> session thread (and we're back to the dangers of mutable state again).

Isn't that a complicated pattern, since shared parameters handle that
case already?

> As long as we can suitably discourage  
> people from using it as a day-to-day inter-thread communications  
> system ;-)

But don't overdo.  Scheme is IMHO the only language, which does not
impose style constraints on it's users.  I consider that an advantage.
(But I agree to discourage bad ideas like this one. ;-)