It's frustrating when you write a %macro function and/or a %do loop, and the DATA and PROC steps inside are not colored according to the usual syntax highlighting.
This was suggested as a feature back in version 9.1, but it still hasn't been fixed.
It sounds like you are frustrated, which I completely understand. Macro programming can be very frustrating.
I am not a macro expert, but I think I understand why this seemingly excellent suggestion might not be possible to implement. From a language point of view the content of a macro is just text. Text can be inserted anywhere, and without context that text can't get color coded.
Here's an example. Suppose that you write the following macro:
%macro doit(procname, dsname, varnames);
proc &procname data=&dsname;
Now to you the programmer, you think that the text contains special keywords like PROC and DATA= and VAR and RUN. You would like to see those keywords colorcoded because you intend to call the macro like this:
%doit(means, sashelp.class, height weight age)
Unfortunately, there are other instances in which text in the macro is syntactically valid. For example, the macro might be inserted into a string:
text = "%doit(X,Y,Z)";
In this context, nothing in the macro is a keyword. The syntax highlighter does not color keywords in the string "proc freq; run;" even though the string contains SAS keywords that would be colored in open code.
Another possibility is that this macro is actually part of a DATA step. Again, in this usage none of the tokens in the %doit macro are keywords:
data = 2;
%doit(=, 2, =3)
proc print; run;
In short, macros are just text. As such, they have no context. Without context, there is no way to apply syntax highlighting. I hope this makes the situation a little clearer.
From a language point of view the content of a macro is just text. Text can be inserted anywhere, and without context that text can't get color coded.
Thanks, Rick. Going back to my experience in C programming, this makes a lot of sense. You're right; because of unpredictable context, it doesn't make sense to syntax highlight everything.
Correct me if I'm wrong, but I believe %do loops could still be highlighted. Maybe not if they are within a macro, but outside of a macro, aren't they just loops?
%do loops have to be inside a macro. Similar with %if / %then constructs.
I do not think of a %DO loop as a loop. I think of it as a preprocessor instruction to generate text a certain number of times. The text might change if it depends on the value of the counter macro variable. The %DO loop merely resolves to some chunk of text, which again has no context.
We can always argue it is not feasible or a bad idea on theoritical grounds because macros process text, etc.
Yet it is useful, even if the color parser will sometimes get it wrong (it is already confused at times anyway). Better still, it is possible.
I upvoted the sensible suggestion, and here is a (partial) workaround. Just add this dummy macro at the start.
%macro color; %macro _; %mend _;
Thanks, @ChrisNZ, this is fantastic!
I agree that we could argue all day. Maybe this could be an option, so users can always turn it off if they don't like/need it.
As a work around, you can add this "local" macro variable near the top of your macro and it tricks SAS into thinking the MACRO has ended, and the syntax coloring is turned on. I don't recall where I found this, but I've been using this since 2011.
%LOCAL a ;%LET a=%NRSTR(%MEND); %*--to get SAS-Coloring Back;
I/S Management Strategies, Ltd.
Im sorry, but I find it beside the point, and a little whimsical to argue that the reason is based on how the interpreter works.
We are talking user interface here, you can program that without changing how SAS interprets Macros as text, easily.
My speculations is that this is a case of an endless backlog poorly attended to, and the fact that these comments are being deflected like this is really not appreciated, considering the prices of SAS products.
@Gardhi, I stand by the conversation above. While I still agree it would be nice to have this as an option (perhaps off by default), it makes sense logically as whatever is inside a macro isn't necessarily following the same syntax.
For example, I've used macros to contain optional where clauses for proc sql queries. And I've used them to represent functions that get evaluated in multiple places in code. Neither of these things would I want to see syntax highlighted as if they were open code.
I've been using the snippets mentioned above when I want to write and/or debug macro code that could be syntax highlighted. I typically include a link back to this thread or this sasCommunity.org tip.
@paulkaefer I think that seems very sensible, dont get me wrong
I was just a little disgruntled by the presentation of a non-existing constraint, especially seeing how poor programming standards are in SAS Base and that people suffer these work arounds for years.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.