Re: [Chicken-users] Bug with #!optional in Chicken 4.8.0

[John Croisant]

On 10/17/12 4:22 AM, Felix wrote:
> > So I wonder: is there any problem with simply adding support for a
> > second arg to the parameter-functions, without removing the arg check
> > for all procedures that use #!optional? Even in Chicken 4.7,
> > parameter-functions silently accept extra arguments, so there would be
> > no user-visible change in the way parameter-functions are called.
> That is correct. The first problem here is that there exist procedures
> that behave like parameters, but aren't ("current-input-port", for
> example - this has historical reasons). The second problem is that
> there is no reason "parameterize" shouldn't work for any procedure
> with a single optional argument.
> [...]
> No, you are basically right. Doing the check would be better (not
> *that* much better, but it would be The Right Thing to do), including
> a proper implementation of parameters (perhaps with 2 different entry
> points, or some handler hidden inside the parameter closure, or
> whatever). I just can't do it right now.
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.

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

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?

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.

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.

- John

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