[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: John Croisant
Subject: Re: [Chicken-users] Bug with #!optional in Chicken 4.8.0
Date: Wed, 17 Oct 2012 17:44:13 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1

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

reply via email to

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