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
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: the
top-level list, that's why their packages don't matter (except for CL:LOOP).
(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
Zach suggested 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