> What do you exactly mean by "fancy lambda-list" features? Remember that
> my soul hasn't been tainted by CL yet. :)

I like either:

- Fixed number of required positional arguments
- Fixed number of optional positional arguments
- Rest argument

or:

- Fixed number of required positional arguments
- Keyword arguments

Both of these have been good for countless real-world uses, and are
quite easy to read and write even if one is not familiar with the
details of the language.

Other types can be useful as well, but I haven't seen a case where I'd
judge them more useful than the complexity.

Here are all of the different types of lambda-lists CL has:
<http://www.lispworks.com/documentation/HyperSpec/Body/03_d.htm>. Even
the table of contents is daunting :)

The ordinary lambda list grammar (used by `defun`) is:

lambda-list::= (var*
                 [&optional {var | (var [init-form
[supplied-p-parameter]])}*]
                 [&rest var]
                 [&key {var | ({var | (keyword-name var)} [init-form
[supplied-p-parameter]])}* [&allow-other-keys]]
                 [&aux {var | (var [init-form])}*])

That's difficult even to read, macro lambda lists are more complex. A
lot of the CL spec is like this.

Don't get me wrong, they did a great job specifying everything
consistently and in meticulous detail. But it's difficult to escape the
conclusion that there is just too much stuff. There are network
protocols simpler than this.

> If you really want to exclude this from SRFI 177, you should reword the
> reasoning as it really has nothing to do with technical limitations as
> the parameterize example shows.

You're right. It was written before your parameterize idea. I'll edit it.