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