An Idea Exchange for SAS software and services

by Regular Contributor
on ‎05-26-2015 03:25 PM

This construct is easy to read and code with the goto and label statements;

%macro go_to(label=abc);


   %put actions for &=label;

   %goto exit;


   %put actions for &=label;

   %goto exit;


   %put actions for &=label;

   %goto exit;






Ron Fehd  macro maven

see also

Edsger W. Dijkstra - Wikipedia, the free encyclopedia

E.W. Dijkstra GoTo considered harmful

by Trusted Advisor
on ‎05-27-2015 10:52 AM


This method is useful for simple cases, however, there are a few problems it does not address:

1) There is no handling for when a label does not exist

2) Your criterion has to be a valid SAS name (i.e. non-numeric, etc...)

3) You cannot evaluate the criterion through multiple tests

Currently, the best alternative is just simply using %if/%else/%do blocks and this mostly falls under the topic of stylistic preferences, in my option.

by Regular Contributor
on ‎05-28-2015 12:50 PM

Hi FriedEgg

I am aware of the deficiencies of my suggestion.

I wanted to show that there is another more simple way to code an %if ... %else block.

Not that I recommend it, but that the functionality is there.

I was polled many years about whether I had a macro named %in.

"No." I replied, grateful that someone in SAS R&D thought enough of my opinion to ask.

When the macro implementation of the in operator was released,

it took about a month before HelpDesk got a call from someone with a macro named %in.

take a look at the documentation for the macro in operator now:

you need to turn on the feature, name the delimiter etc.

Take a look at what you are proposing:

macros %select with and without parameters

macros %when and %otherwise

I am sure you'll find several people with macros with those names in their libraries.

remember the SAS macro language is a preprocessor,

its job is to replace text and expand macro definitions.

making it look or read like other program languages does not increase its power

and as the story about the in operator was meant to show,

it can be a headache for both the developers and HelpDesk.

take pity on them every once in a while

Ron Fehd  keep it simple

by Trusted Advisor
on ‎05-28-2015 05:39 PM


I agree with you on the point you are trying to make about the name collisions, and I also agree that this adds no new functionality.

by Frequent Contributor
on ‎05-29-2015 10:38 AM

I think the lesson to be learned here is

   Don't use base SAS reserved words for macro names!

I am in favor of the proposal, and SAS should add an option to turn it off, as they did for %IN.  Presumably %select will be like %if, usable only in macros and not in open code, so a macro writer will know whether the option is needed.

%macro do_my_stuff / macselect; 

    would allow use of %select, %case, and %otherwise inside the macro.

%macro do_my_stuff / nomacselect;

   would not allow use of those keywords as macro language statements, and would use whatever the user defined externally.

This wouldn't work if %select is allowed in open code, but that would make me so happy I wouldn't care.  I can't count the number of times I've had to write a macro for the sole purpose of using a %IF statements, and it's a botheration.

Another suggestion: a system option that will cause a warning message or note to be issued if the user creates a data step variable, macro variable, or macro that is the same as a system keyword.  With the option of turning off the message for individual keywords.

by PROC Star
on ‎07-16-2015 12:21 AM

>   I can't count the number of times I've had to write a macro for the sole purpose of using a %IF statements, and it's a botheration.

No need for this since V9:


  %sysfunc(ifc( %length(&previous_datasets.)

              , set &previous_datasets.%str(Smiley Wink by CUSTNO

              , CUSTNO = . ));


by Super User
on ‎07-16-2015 05:09 AM

That's pretty cunning, almost devious...

I've also avoided creating macros using CALL EXECUTE in a DATA _NULL step instead.

Every programmer has their own pet preferences.

by PROC Star
on ‎07-16-2015 06:14 AM

Thank you. I take this as a compliment. 

The vvaluex function also allows to use/manipulate variable names dynamically without using the macro language. As you say many ways to pet a cat.

My worst macro language abuse must be this (still useful sadly; SAS, we're waiting for a proper way!):

I always like pushing the envelope, hence why I wrote Smiley Happy

Idea Statuses
Top Liked Authors