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

[F. Wittenberger]

Am Montag, den 11.08.2008, 07:28 -0700 schrieb Elf:
> absolutely not.
> 
> first, why will it be difficult for you to set up a clean build environment?

Because I'll have to rebind parameterize, which is then going to be
available to eval, where it could access parameter objects, which where
created with the default make-parameter since I do not know how to
rebind make-parameter and be sure to do so before any other parameters
are set.  Also code compiled with the standard implementation would not
work correctly anymore, if those shared parameters where passed in.

This all looks to me like the box of pandora full of sources of
confusion.

> second, your patches will flat out not work in default chicken.
> 
>      A) why are you sending a patch of the debian rules customised for your
>         box?

Sorry, this was a mistake.  I've been interrupted in the middle of
editing.

>      B) you are fundamentally changing the representation of parameters.

Really?  At least that (supposed to be - modulo bugs I made) all
compatible with the old version.

It introduces just two more comparison in the value look up.  And one
more optional parameter to make-parameter.

Does this already qualify as a fundamental change?

>      C) redundant/unnecessary code - you duplicated a case.

I can't see that one.

>      D) inconsistent naming scheme

Which one would be better?

>      E) there are around 300 occurences of parameters in chicken core.  many
>         eggs use large numbers of paramters.  have you tested fully, or even
>         partially, the effects of changing structure?  mucking about with
>         parameters can and will break just about everything.

I have tested the implementation.  But to which extend should this be
done.  The new case applies only if there's a shared parameter object
and it is called from the modified parameterize.  I had preferred to
pass some special key, which the user can not produce, but I don't know
how to express that in chicken.  The standard case will just ignore the
additional argument.

Against which possible impact should I test?

> third, there has been no consensus and very little discussion regarding 
> parameter models yet, so methinks you may be jumping the gun.  if you want
> a shared variable between threads, dont make it a parameter.

The point is: there is a large code base, which is supposed to run under
different Schemes.  I'm trying to find the minimal diff.  It's already
hard enough and I'm a not entitled to break the deployed version at any
time.  (I just spent 3 days without success trying to figure why this
test case
http://lists.gnu.org/archive/html/chicken-users/2008-08/msg00029.html
fails if and only if the thread hangs on tcp *and* there are two nested
condition handlers (while other ways to hang or just one condition
handler will work as to be expected).

>  if you want
> a thread-local variable, parametrise it.  i dont see why this requires 
> changing
> core structure.

All I need: a thread-local variable and a way to set it's default value
from a thread, while accessing the thread-local one within parameterize.
How should I do that?

> -elf
> 
> On Mon, 11 Aug 2008, Jörg F. Wittenberger wrote:
> 
> > Hi all,
> >
> > since there where no more responses on my last post to this thread, I
> > decided that it might be the best to supply a patch to this list, which
> > adds a procedure "make-shared-parameter" extending the existing
> > make-parameter in a compatible way.  The attached diff (against svn
> > revision 11597) should have no impact on the standard procedure
> > make-parameter and the parameterize macro.  However if the parameter is
> > a shared parameter, only parameterize will create a local binding for
> > that parameter (or the to-be-undocumented interface: call the parameter
> > procedure with a second argument).
> >
> > I'd appreciate if this could make it into the chicken core - otherwise
> > it's going to be a pain to set up a clean build environment in my case.
> >
> > Best regards
> >
> > /Jörg
> >