Nitpick: local variables named "cut", "list", "all", and "mem" will not clash with Arc built-ins, because function names which clash with local variables will simply be overridden. It's only with macros such as "fn" which will fail.
That said, I've since added lib/pm.arc which defines the "pm" macro and shadows pat-match.
Good point on the nitpick, although that still means macros that expand to use those functions and any uses within the scope of the variable will fail.
Adding an extra lib for just in case you want to use this function seems like a bad compromise to me. It seems like one of those cases where you could do a language feature one way to make one camp happy, another way to make the other camp happy, and you end up doing both which just makes the language, larger, more redundant, and confusing as a result.
We should either make the name shorter or not, not provide a shorter alias that will just confuse people.
I've just pushed a better compromise to the wiki, renaming pat-match p-m which is shorter but unobtrusive.
As a separate note, now that we have p-m, wouldn't it be better not to use defpat at all? In fact, if we use "pm" instead, pm:def is just as short.
> As a separate note, now that we have p-m, wouldn't it be better not to use defpat at all? In fact, if we use "pm" instead, pm:def is just as short.
That's correct, although p-m:def does have a symbol on the top row of the keyboard (-) and shifted symbol on the home row (:). I'd suppose that using pattern-matching in def is significantly more common than all the other cases combined. Although in terms of readability, certainly p-m:def would raise the question of "wtf is this?" only once and introduce the pattern-matching modifier completely, whereas "p-m:afn" and "defpat" will introduce them separately.
