[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: |
Wed, 17 Oct 2012 04:22:41 -0400 (EDT) |
>
> Here is how I understand the situation: in order to avoid unnecessary
> computation, we want to avoid invoking the guard procedure when the
> old parameter value is restored at the end of parameterize. So, we
> need parameter-functions to accept a second arg, which is a flag to
> tell it to bypass the guard procedure.
Right.
>
> 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.
>
> The only bad effect I could see, would be that Chicken users might
> think the ability to bypass the guard procedure is a real feature of
> Chicken, instead of a hack to make parameterize more efficient. But,
> that problem could be avoided by checking that "bypass guard" argument
> is a certain unexported symbol (maybe even a gensym) that Chicken
> users would not (normally) have access to. To put it into pseudocode,
> a parameter-function might behave something like this:
A good point - this would make misinterpretation of the argument a tiny
little bit less possible.
> Maybe I have misunderstood something, and this solution would not work
> for some reason. If so, please help me understand.
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.
cheers,
felix