>> > 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 _______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
