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?
Plus
should 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
,Times
and 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? $\endgroup$Plus
andTimes
are 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+1
Look ma! NoPlus
! But you still get 2. HoweverPlus[1,1]
remains unevaluated. $\endgroup$Plus
works for numbers and symbols was just something that seemed strange to me. $\endgroup$