Paul wrote:I don't know what loop code CLISP uses. Most implementations can do this. (Any reason you can't compile the MIT loop code on CLISP, if you want?)
Ok, I could, but then I would have to distribute MIT loop code with my libraries, which is not very nice. I would rather have my project depending on iterate, for instance.
And what source do you have to know that
most implementations can do this? And by saying that most implementations can do this, do you mean they can do this in the same way, or in different ways? Because having the same feature among many implementations but varying on the way that that feature is used... it is not good enough for me.
If there was a standard, though, and implementations followed that standard, or at least a compatibility layer, then that would be enough.
Paul wrote:gugamilare wrote:Not to mention you are using internal functions, which can change at the developers' will.
Haha. It hasn't changed in...umm...20-odd years; I doubt it's going to change in the next few weeks

{Besides, they're not really "internal internal"; they're put there to allow extension}
Well, they did change in SBCL, at least the function names and the package in which they are located. This functionality is good for people who want to use them and don't care much about the portability of their code (e.g. when sticking to one implementation), but that is not everyone.
If it makes you happy, though, good for you
