> As far as I can tell from the discussions here, Steven
> and you stated a preference for the shortened names, and
> that's it.

Plus Mark, plus me - all backed "comb()" specifically.

> I find it hard to imagine anyone needing combinations without
> also needing permutations, and I didn't think it was necessary
< to explicitly say so.

Of course it is.  Merely saying something is possible is no reason at all to do it.  The original report didn't say anything about counting partial permutations, and so it's "feature creep" on the face of it to tack that on.

I personally have scant use for `perm()`, but have written my own `comb()` many times.  Far more often than I've written a `factorial()` and a `product()` combined, but I've written each of the latter more than twice, and a `perm()` not even once.  Especially if `prod()` (the topic of a different report) is added, the case for adding a `perm()` gets weaker (rising and falling factorials are special cases of what `prod()` does, and `perm()` is just an instance of falling factorial).

Which doesn't mean `perm()` must not be added ;-)  You're now the first to say it _would_ be useful, which is a start.  Can we get a second?

In any case, I don't want to _see_ this report get bogged down by feature creep:  `comb()` is what it was about from the start, and everyone so far has agreed `comb()` would be useful.