# Force a function to report argument type mismatches

As a relative newcomer to Mathematica, I am still frequently caught out by coding errors that, at least by default, MMA does not indicate to the front end, in particular when I define a function and the argument types and then accidentally pass an argument of the wrong type.

For example, if I define

f[x_Integer] := x + 1;

and then call

f[{1}]

it is returned unevaluated because {1} has Head "List" and "Integer" is required.

This sort of thing tends to happen to me when I first test a larger and more complex function where other errors are to be expected, in which case my attention usually goes directly to the code.

Question: How can I write functions and declare the argument types on which the rest of the code may depend and let MMA tell me when I have passed an argument of the wrong kind?

• Compile your function, and you will get what you want, I suppose. – Αλέξανδρος Ζεγγ Sep 29 '18 at 8:36

## 1 Answer

One way to write a function with argument checking is to write subroutines for your function f that handles the actual calculation, and then do the argument checking in the main routine for f.

As a highly simplified example, let's call the subroutines for f intF:

intF[x_Integer] := x + 1
intF[x_ /; ArrayQ[x, _, IntegerQ]] := x + 1


so that f should only work for an integer or an array of integers.

We can then define error messages that f can emit:

f::nlst = "The argument 1 is not an integer or an array of integers.";


From that, you can write f like this:

f[x__] := Module[{nargs, res},
nargs = Length[{x}];
res /; If[nargs == 1,
If[Head[res = intF[x]] =!= intF,
True,
Message[f::nlst, x]; False],
Message[f::argx, f, nargs]; False]]


The main point here is the use of Condition[] (/;) to do the argument checking; recall that in the expression expr /; test, test should be something that evaluates to True or False, and expr will only then be evaluated.

In this example, the first check is a simple argument count, done by checking if {x} has length 1 (i.e. f was only passed one argument). If the test fails, then the part Message[f::argx, f, nargs]; False gets evaluated, and since the last result is False, we get no evaluation of res.

Note, however, that I did not define the message f::argx. In this case, the message text is taken from General::argx.

If the check of the argument count is passed, we get to the inner conditional. In there, we evaluate Head[res = intF[x]] =!= intF. Two things are done here: the result of the subroutine intF[x] is assigned to res, after which it is checked if evaluation occurred (i.e. the head of res is no longer intF). If this test is passed, we get the ultimate result True for the condition, and thus the previously evaluated res is returned. Otherwise, Message[f::nlst, x]; False gets evaluated.

With this, f[3] and f[{{1}, {2}}] will evaluate as usual, but f[2.] and f[{{5, 6}, {4}}] will throw the message f::nlst, while f[1, 9] will throw the message f::argx.

• Very nice & clear exposition, thx! Question though: the head check tests evaluation so doesn't say anything specific (just like seeing the fn unevaluated in output) & the message f::nlst seems to assume that evaluation did not occur because of the mismatch - but what if evaluation failed because of a coding error rather than an argument mismatch? I don't know MMA well enough to know whether that is actually possible, but I think I recall function definitions that seem to be OK (the symbol gets defined on shift-return) but don't evaluate even with correct arguments. Or am I mis-remembering? – Julian Moore Sep 29 '18 at 10:11
• PS Part of my Q is really - when MMA checks arguments and finds a mismatch, why doesn't it report that itself? – Julian Moore Sep 29 '18 at 10:13
• I'll try to write additional details later, but to quickly answer your second question: Mathematica is allowing for the possibility that you might write additional definitions later. Using the f example, if I add a third definition for intF that covers input not covered by the previous definitions, then f gets to use that definition as well. – J. M.'s technical difficulties Sep 29 '18 at 10:40
• You are most kind; but if MMA is checking against all symbols is an unevaluated output defined to mean no matching symbol definition - and any other error in e.g. code is always indicated some other way? – Julian Moore Sep 29 '18 at 11:33
• "...if Mathematica is checking against all symbols, is an unevaluated output defined to mean no matching symbol definition" - it is, first and foremost, a pattern-matching language; it will do something only if it has been explicitly told how to handle objects that match a defined pattern. So, in the intF case, I told Mathematica how it should deal with integer input in one definition, and how to handle an array of integers in a second definition. Any other thing not matching those two defined patterns is left unevaluated. – J. M.'s technical difficulties Sep 29 '18 at 12:15