I have a very simple question about redefining basic built-in functions, such as Plus. I'm pretty sure someone must have asked a similar question around here, but I couldn't find one. Consider the following code:
Unprotect[Plus];
x_ + y_ := x y
Protect[Plus];
For symbols this works as expected:
x+y
(* ---> x y *)
For numbers, however, the new definition does not work:
1+2
(* ---> 3 *)
Of course I know that it is stupid to use something like this and that defining functions or using upvalues etc. is the way to go here, but I'm really interested in why this happens. Can the pattern for Plus be defined in such a way that it works for numbers as well? Is Plus[1,2] evaluated internally before the pattern can be matched?
Plusshould not be relevant to the user. To me, this seems one of those internal details which can not serve you well even if you know them.Plus,Timesand perhaps a few more fundamental functions have deviations from the standard evaluation semantics, so that certain buit-in rules like the one you illustrated apply before the user-defined rules. The whole fact that this was done in this way shows that those rules were considered very fundamental by developers, which brings the question again: how would the knowledge of exact semantics here be helpful? – Leonid Shifrin Feb 06 '13 at 00:13PlusandTimesare deeply wired in the system and cannot be modified beyond a certain point, as they're essential to pretty much everything else. For example, try:Unprotect@Plus; Remove@Plus; 1+1Look ma! NoPlus! But you still get 2. HoweverPlus[1,1]remains unevaluated. – rm -rf Feb 06 '13 at 00:14Plusworks for numbers and symbols was just something that seemed strange to me. – einbandi Feb 06 '13 at 00:17Plus, but a comprehensive answer that also touches upon what might break if hypothetically one were to do this would be really great to have. – rm -rf Feb 06 '13 at 00:24