3

From Sample 35591,

The IN operator can be used in the %IF statement only when the MINOPERATOR option is set in the %MACRO statement or as a SAS® system option.

Requiring a separate option for macro processing seems like an unnecessary complication. Of course, the macro IN syntax and what it can process must be different from the DATA step IN because of the nature of macro processing. But the implementation forces the programmer to keep track of two different IN's, despite them being logically identical.

  1. Are they not logically identical?
  2. Is requiring a separate option for the macro IN meant to remind programmers of the differences from the DATA step IN?
  3. Or, is there a situation or backwards compatibility concern which requires the macro IN to be implemented this way?

Documentation for MINOPERATOR.

Joe
  • 62,789
  • 6
  • 49
  • 67
Lorem Ipsum
  • 4,020
  • 4
  • 41
  • 67

1 Answers1

7

The Note says that this is only available in SAS 9.2 and later. Previously, there was no IN statement for MACRO processing. Macros are strings and "IN" is a valid string. The option is required to tell the Macro Processor that IN is now a keyword. If they just made it a key word, legacy code which might contain "IN" would break.

So #3.

DomPazz
  • 12,415
  • 17
  • 23
  • 1
    Backwards compatibility for sure. I once worked at a bank where an early release (which used the in operator by default) broke some legacy code.. – Allan Bowe Jan 27 '17 at 16:41
  • FWIW, I wondered why SAS didn't create a `%in`keyword and tried implementing my own. Creating an 'in' macro function: `%macro in; %let in = in; ∈ %mend;` Then testing it: `%put %in;` This generates the following note in the log: `NOTE: %IN will become a reserved keyword of the SAS Macro Language in a future release of the SAS System. Changing the name of this macro will avoid future conflicts.` – Lorem Ipsum Jan 31 '17 at 15:40