[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: Sun, 14 Oct 2012 19:29:10 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1

On 10/14/12 7:20 AM, Felix wrote:
From: John Croisant <address@hidden>
Subject: [Chicken-users] Bug with #!optional in Chicken 4.8.0
Date: Sat, 13 Oct 2012 20:34:26 -0400

In Chicken 4.8.0, procedures defined with #!optional no longer signal
an exception if invoked with too many arguments. For example:

(define (foo x #!optional y) (list x y))
(foo 'x 'y 'too 'many 'args)

In Chicken 4.7, this would signal an exception, because the foo
procedure expects a maximum of 2 arguments. In Chicken 4.8, the extra
arguments are simply ignored.

I think this is a bug, because the docs for "Extended DSSSL style
lambda lists" say:

If there is no rest-parameter  and no keyword-parameters in the
parameter-list, then it shall be an error for any extra arguments to
be passed to the procedure.
That is correct. The check has been removed and conflicts with
the documentation. I will update the docs accordingly.

The check has been removed to accomodate a terrible hack for handling
re-initialization of parameters with "parameterize", and for a slight
performance win. The hack is so terrible, I hardly dare to talk about
it in public. On the other hand, I see no problem in allowing extra
parameters to lambdas with rest/optional arguments being silently
dropped - it has been done before.


The new behavior may not break very much currently existing software (although it did break some of my unit tests), but future software written in Chicken will start to depend on the new behavior, so changing the behavior back in the future *would* break existing software. So, we should address this soon, while the pain of changing back is still minimal.

The old behavior was useful and valuable for (at least) two reasons:

1. It provided clear and immediate feedback if the procedure was called incorrectly, making the mistake much easier/cheaper to fix. (Even experienced professional programmers make this kind of mistake sometimes.)

2. It was consistent with the behavior of optional args in many other widely-used programming languages.

The new behavior can be useful in some situations, but it was already very easy to implement: just add a rest arg to any procedure that should ignore extra args. On the other hand, it takes a significant amount of code/effort for developers to (correctly) reimplement argument count checking in their own libraries and applications.

So, for all those reasons, I think this should be considered a bug and fixed as soon as possible. Perhaps if you describe the parameterize problem (or link to discussion about it elsewhere), someone can think of an alternative solution that will not require changing the behavior of optional args?


- John

reply via email to

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