Thanks for the input Joerg.  That said I think that there still needs to be a discussion here.

I think that it is important to note that Budden has sufficiently convinced me that this will cause approximately zero symbol collisions because 99% of all Iterate extensions are done by specializing on the keyword options of existing clauses. In fact, in the short term, the only possibility of a collision is if someone decides to declare a clause that explicitly collides with one of Budden's keyword shortcuts, like a (defclause :FOR ...). This is probably not a valid concern. As I stated, the real concern I can see is that this could be the first step down the road to limited extensiblility in the Iterate library.

I think that this is a matter of style and consistency, and I'm not sure that style should stop anyone from doing something that would provide a clear benefit. The real question is, will keyword short cuts provide over-all benefit to users or will they be detrimental.  Unfortunately, this extension seems to provide a short-term benefit and yet, possibly, a long-term detriment.  This seems to come down to a judgement call of the maintainer and the community.

Zach

On Wed, Oct 17, 2012 at 6:55 AM, <Joerg-Cyril.Hoehle@t-systems.com> wrote:
> Hi,
>
> I don't know if I qualify as a maintainer, however you'll see from the
> ChangeLog that I've spent a lot of effort a few years ago to make
> Iterate work in an ANSI-CL environment and fix numerous bugs.
> I would not appreciate new developments that kill the original design.
>
> Zach is very right. Packages are the CL way to have Iterate deal
> with extensions. That's why Iterate keys all extensions on symbols.
> symbols => packages.
>
> Iterate is not LOOP. With loop, all clause "keywords" are found flat in the
> top-level list, that's why their packages don't matter (except for CL:LOOP).
>
> Zach suggested
>>(iterate:defsynonym :for iterate:for)
> Not sure if that works, because of the order of tests in the parser.
> It would be a fancy user-level hack. By that I mean it's a nice text
> book example, and a user may like it and use it in his/her code.
> But don't release code and libraries with that because as Zach pointed
> out, it would kill extensibility as several extensions would fight for
> the same keyword!
> That conflict does not happen with symbols of different packages.
>
> Paraphrasing KMP, CL is a tool for building large systems.
> Don't break that.
>
> Regards,
> Jörg Höhle