I personally have a tendency to use short variable names; I'm pretty sure I've used "pm" as "port mapping" (this is in electronic development automation) at least once. As for ptrn - well, all it takes is one Arc programmer to stumble on that name.
Heck, maybe Arc should be a Lisp-2. with values (including functions) on one namespace and macros on another. Then select macros by, I don't know, putting some syntactic marker for "use macro for this symbol" or somesuch.
Okay, sure, but the same could be said for other short names like "cut," or "list", or "fn", "all", "mem", etc. Given that Arc is a Lisp-1, you have to make compromises between terseness and commonality. And in this case it seems pretty clear to me that this function is useful enough and "pm" rare enough as an identifier (never used once in arc-wiki) that the compromise should lean towards a shorter name.
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.
I'm still a noob, and my idea could be completely off base, but I think that it could be possible to devise a system that allows something like optional namespaces. The idea would be to have each symbol in the environment map to a table rather than directly to a function or variable. The table could have one entry per type (for example, pat's table could have one entry that's a macro, one that's a function, and one that's a variable). In standard cases, the value lookup function could return the entry that was last added to the hash table and thus mimic a Lisp-1 for all purposes. However, if the programmer specifies the type of a symbol, then the table would return the corresponding entry. There could be an fairly unobtrusive syntax for this. In one such syntax, the symbol pat would be:
I'm sorry, but could you explain your example a bit more? I don't think that I understand the issue here. If pm is redefined as a table through the let, why wouldn't we be able to access the macro version through the modifier? the table would clobber the variable version (@pm), but not the macro version right?
Local variables never override macros. In the first case above, the let will return the expected value correctly, because pm at that time hasn't been defined yet. In the second case, it will not return the expected value, because pm is defined as a macro, and (pm 1) gets replaced with whatever (pm 1) expands to, let notwithstanding.
