chicken-users
[Top][All Lists]
Advanced

[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



reply via email to

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