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

[Elf]

On Mon, 11 Aug 2008, Jörg F. Wittenberger wrote:

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

no, but changing from a cons structure to a slotted structure does.  changing
the meaning of the cells in the cons does as well.


> >      C) redundant/unnecessary code - you duplicated a case.
>
> I can't see that one.

sorry, my error on that one.


> >      D) inconsistent naming scheme
>
> Which one would be better?

is it guard or guard+type?  this was more of a personal pet peeve rather
than a fundamental flaw, as you changed it one place but kept the previous
behaviour in the new case.

i must add two that i missed originally as well, which is 'breaking backward
compatibility' and 'inconsistent semantics of the cons cell handling'

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

if youre mucking about with parameters, you should test things like http,
spiffy, various sql bindings, some of the format eggs, sxml, etc.  almost
everything uses paramters.  you should test to see what happens when you 
use certain declarations.  you should test all of the functionality listed
on the 'parameters' page of the manual.  full testsuite.


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

are you using thread-signal or thread-terminate, btw?  it DOES matter, very 
much, which you use, i think.  it would probably be advisable to read the
bloody manual for tcp as well, as there are parameters in place for setting
timeouts already.  i would also suggest rtfm for srfi-18, as it has timeout 
args to most of the procedures as well.

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

this sentence does not make sense.  does setting the global default change
the values on all the copies currently in threads?  if so, its not local.
how does setting the global value affect those already around?

i would probably do something like:
(make-parameter (vector <data>))

for shared parameters, since only a shallow copy is done, all values would be
synchronised.  then you (vector-ref (param)) and (vector-set! (param) 0 <val>).


-elf