01-16-2016 12:39 PM - edited 01-16-2016 12:40 PM
Someone posted this quesiton on StackOverflow https://stackoverflow.com/questions/34820068/function-style-macros-vs-proc-fcmp-functions but it is probably better suited for discusion here.
I am considering replacing a lot of function-style macros with FCMP equivalents. Before I go through this process I was wondering what limitations FCMP has compared to function style macros? Has anyone else been through this process and are there any reasons why I would notwant to do this?
My reasons for wanting to do this is to make code easier to read and maintain, and less error-prone. I believe that FCMP functions are easier to read than macro code for most SAS programmers.
What do people think?
01-16-2016 03:13 PM
I am not that familiar with functions build with PROC FCMP, but a SAS macro has one of the most user friendly calling interfaces I have seen. You do not need to use positional parameters and instead can use names in the macro call. You can even use the names in the macro call when the macro was defined to support positional parameters. I would hate to give that up.
01-16-2016 04:33 PM
01-16-2016 05:13 PM
I promised myself to use FCMP more in the future, but you should beware it is not just another way to write the same thing (it is not sytactic sugar).
Function-like macros are interpreted before compilation. If you write them inside a data step, the same code is compiled, no mather how many observations you will process.
If you call FCMP functions, a call is made for each observation.I expect this to be a serious performance penalty in benchmarks, especially if I see how loosly coupled the logic in and outside the FCMP are.
The positive sides I see are:
1. function like macro's can have unexpected side effects. FCMP functions don't (as far as I understand)
2. FCMP functions can run complete procedures or datasteps by calling a macro for each observation of a dataset. See also also http://stackoverflow.com/questions/33817518/sas-how-to-return-a-value-from-a-sas-macro/33830485#3383...