FCMP: Function Compiler - this is used to extend the SAS language by providing compiled functions to further code. Its only plus is that it can be better speed wise in processing data, so useful perhaps in big data where speed is essential. Yes 'Compiler' it is. But FCMP pushes the function to a data-set with plain text (outlib=) and not the 'obfuscate my code to make it unreadable' kind. I can't check the %macro() as easily with a so simple proc print on 'outlib' data-set. The FCMP Documentation stresses more than once that function => data in SAS data set.. We can share the source file creating the FCMP functions (as we do for macros), Therefore we have cross-platform guarantee if we follow the rules. Never tried to dump/load the data-set on an other platform. The SAS documentation goes full length on the 'save' part, but not much on the 'load/share' part. How would you just dump a %macro() without the source file? If under proc FCMP, you call platform specific compiled libraries (like C) now yes this is the 'bad bloat' trap, not because of FCMP but the choices made/imposed on the users. Side note: I wouldn't be surprised that standard function (e.g. length ) call platform specific binaries 🙂 Macro: Inbuilt text/find/replace system - this is used to create code which can be expanded by the pre-processor into full Base SAS code by use of special terminologies. Here, the 'expand' phases are indeed different (is the word 'expand' even relevant for FCMP functions?). I need to first let the data speaks (or load them in PDV if you prefer) and then choose a dynamic path based on the data (more post-processor way). The use of %macro() pre-processor is just to often getting in my way by freezing the decision path to early. For almost all the PROC options, functions are not an options and one must rely on macros… or wait… I can't resist: PROC FCMP outlib=work.fun.fun;
Function printds5(x $) $;
Length sascode $ 200;
sascode = catb('proc print data=', x, '(obs=5); run;');
Return (sascode);
endsub;
run;
option append=(cmplib=work.fun);
data _null_;
set sashelp.vcolumn(obs=10 where=(libname='SASHELP'));
libds = catx('.', libname,memname);
rc = dosubl(printds5(libds));
run;
proc print data=work.fun;
run; FCMP as an alternative non macro SAS code pre-processor ! (dummy example to make a point) 1) It is a compiled to catalog language, that is the one main point of it and where the one key benefit of it is. Ignoring that is not optional. Again, from the documentation it is saved as a standard SAS data-set, the 'language catalog' is SAS. That is quite powerful: you can query your function data-set with PROCs ( meta funky ). 2) Macro code, whilst it can be compiled to a catalog (bad, code hiding really is bad), does not have to be, it is processed as part of the SAS subsystem called the pre-compiler, and macro does not get "compiled" it is simply a find/replace system whereby special character sets are picked up in the text and replaced or expanded per macro rules. That is one of my issues with macros. One level & or % is almost always fine, but passed this point you have to resort on context dependent use of &&&myvar. or %str, %nstr. You can trust the user to go past your defenses, add a new pre-process cycle and find a blind spot. That is to me obfuscation and maintenance bargain. But sometimes, in SAS, there's no way around of course. 3) Users coming into SAS learn Base SAS and macro SAS as a minimum. Therefore being able to pick out in code where & and % are and knowing that is macro is fundamental, anything else is assumed to be part of Base SAS. Therefore creating your own functions - unless they are named specially - will simply confuse users, why can I not find documentation on the function printl on SAS's website? Well well. user defined macros surely don't have any SAS documentation neither. Or am I missing something? I agree that 'write your own macro' comes before the 'write your own function'. That is a fact. However the application of function (length, trim, max, date…) comes before in beginner SAS curriculum: let spot the '()' in DATA STEPs. Out of the 'Little SAS book': Write %macro(): p209 function: ???? (nooooothing) Application: function: p70 (first!!!) %macro(): p209 (waaaaaay after) I tend to think that function application is more intuitive and don't need much attention. With %macros() you have to be careful and take the time to learn the many pitfalls. 4) As yet I have not seen any "special" benefits of using compiled functions other than on special niche circumstances. Therefore why use it? Base SAS can do almost all tasks (in general faster and more efficiently than user code), and where that is lacking then simple macro can be used. Where I see macro being used a lot is to cover up badly modelled data or a lack of knowledge of Base SAS (excluding SAS atttempts to macrotize everything in their systems as well now, but that is another topic). This does not need to be compounded by further levels of badly written, unsupported, hidden code. My special benefit for FCMP function is: run 'proc' and pass value at Data Step time: the power of late binding in the almighty DATA STEP, that is where my data are. I find it super powerful mega plus. Or recursion. Or use of hash-table or... (no need to quote the FCMP SAS Documentation). Badly written code/decision is on the side of the user, not FCMP. You surely have seen badly written %macro(). So as previously posted, I have no real benefits of using fcmp (except in niche scenarios) that Base or Base + Macro do not cover, and plenty of downfalls, hence the conclusion for me is to not recommend it. And so my conclusion diverge from yours, and they can coexists. I would recommend it more often than not, PROC FCMP is a BASE SAS procedure after all.
... View more