[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]