[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] Bug with #!optional in Chicken 4.8.0
From: |
Felix |
Subject: |
Re: [Chicken-users] Bug with #!optional in Chicken 4.8.0 |
Date: |
Fri, 19 Oct 2012 02:55:10 -0400 (EDT) |
>>
> Now I understand what you mean about parameter-like
> procedures. Supporting them does indeed make the situation more
> challenging. But, if we could somehow distinguish between real
> parameters and parameter-like procedures, we could be sure to only
> send the "bypass guard/conversion procedure" flag when restoring the
> old value to real parameters.
That's correct.
>
> If there is already some way to distinguish between them, that would
> be perfect. Otherwise, maybe we could use lambda decorators to "mark"
> real parameters when they are created in make-parameter? I am not
> really familiar with what lambda decorators can do, so maybe what I am
> saying is not possible (or is just a stupid idea).
This is a possible solution, yes (not stupid at all). It requires a
runtime-test, though, which should be made as efficient as possible.
>
> Of course, instead of writing more and more hacks, there is the option
> of creating "a proper implementation of parameters", as you say. What
> would be different in the proper implementation, versus the current
> implementation? Is this something that an experienced programmer who
> has never before hacked Chicken internals could help with?
Why not? The implementation of parameters is a bit involved: first,
parameters are thread-local, and second, parameters are "inherited" -
a freshly created thread will inherit the parameter settings of the
parent thread. This is done in a "lazy" manner to avoid unnecessary
overhead. See "make-parameter" and "make-thread" in "library.scm"
for more information.
>
> From your earlier comments, it sounds like creating a new
> implementation would have a high risk of accidentally breaking stuff,
> especially because of threading. But that risk could be significantly
> reduced if we create a good test suite before the change. Even if I
> don't know have enough experience with Chicken internals to implement
> proper parameters, I could certainly help write tests.
That would be excellent.
>
> Basically, I really want to see the "proper" behavior of #!optional
> restored, and I am willing to help in any way I can. Just let me know
> how I could be most useful.
That's great, John. If you want, you can take a peek at the current
implementation and bug me or the mailing list with questions.
>
> P.S. I don't know why I care so much about this issue. It's not that I
> depend on #!optional so much. I guess I am just shocked that such a
> basic language feature could be altered without any public discussion
> (that I can find) or even a mention in NEWS. I like having order and
> stability in the universe. ;-)
We all do...
But see commit 1eff1721 in the chicken-core git repository, which
removed the checks and thus brought more chaos and anarchy into the
world.
cheers,
felix