# Design Patterns for System Functions?

Using PrintDefinitions give one a great view into many system functions. Often the design of these symbols incorporate multiple patterns that I see again and again. To name a few:

• For a symbol XYZ, there is iXYZ[], aXYZ[], etc...
• Use of so called “router” subroutines.
• Specialized failure catch/throw mechanisms
• Fancy nonstandard option handlings
• I've never seen an aXYZ -- what's an example? I think of iXYZ as "internal XYZ." The parent XYZ[] does argument checking and possibly other preprocessing of arguments and options; then sends the prepared arguments to iXYZ[] for the main computation. If the main computation fails, the internal function often returns $Failed, which causes XYZ[] to return unevaluated. Something like this: XYZ[args___] := Module[{res}, (* check/process args *); res = iXYZ[args]; res /; FreeQ[res,$Failed]]; As noted, they sometimes use Catch and Throw for a nonlocal return of \$Failed. – Michael E2 Jun 11 at 5:14
• "Fancy nonstandard option handlings" explains why do many builtins have broken option handling ... in particular, why many won't pick up things set with SetOptions. – Szabolcs Jun 11 at 13:20
• I really don't think there many techniques used there which are not in some answers scattered on this site. What you mentioned amounts to using SubValues, local variables shared between the Module / With and the condition, exceptions with custom tags to fail early, delegeation of implementation to dedicated separate internal functions. All of that has been discussed in some Q/As on this site. – Leonid Shifrin Jun 12 at 23:19