I don't understand when statements are compile time.

[carapaxit]

A quote from course programming 2:

The KEEP, WHERE, and FORMAT statements are compile-time only.

I don't understand why those are compile-time. WHERE takes a condition which is true or false depending on the row from the input data. It can't be evaluated at compile-time. What is compiled then?

Trying to understand the logic, if a compile-time statement can have an effect depending on the actual data, then why aren't all statements compile-time? For example, you can do if-else-constructions. Does SAS parse the English words "if" and "else" every time? (If the code is not compiled that's what I expect.) It makes more sense to me to compile those if-else-constructions, and really every statement, to something lower level before execution.

I know there are languages that are interpreted like javascript where an eval function exists. I wonder how SAS compares to that or if it's something completely different.

[Tom]

The distinction is more about statements like DROP/KEEP/RENAME and FORMAT/INFORMAT/LABEL/ATTRIB/LENGTH that just help determine the structure of the data and not the content.  You cannot run them conditionally by using branching logic like IF/THEN/ELSE/DO/GOTO etc. since there is no actual code that runs for every iteration of the data step.  

Not sure if you would consider WHERE as something that is strictly "compile" time.  But it is external to the execution of the actual data step code as it determines which observations are provided to the data step when it actually runs.  So there is no way to run it conditionally.

If you want to run code you have generated dynamically (like the eval() function you cited) then use the macro language to generate the code.  You can execute a macro that generates code. Or just expand the value of a macro variable you have created with code in it.  Or write the code to a file and use the macro language statement %INCLUDE to run the code as if it was part of the original program.

[carapaxit]

Thank you. That makes it more clear. A compile-time statement can't be run conditionally. I just tried this as an experiment (edited version of p201p05):

data monument(drop=ParkType) park(drop=ParkType) other;
	set pg2.np_yearlytraffic;
	if ParkType = 'National Monument' then output monument;
	else if ParkType = 'National Park' then output park;
	else output other;
	
	if ParkType='does not exist' then do;
		drop Location;
	end;
	
	drop Region;
run;

The column Location is dropped even though the condition is never true. It looks like SAS scans the data step for compile-time statements and applies them first, just like conditional column declarations (that I have seen earlier in the course). In the same way it should be impossible to change the WHERE condition while processing rows.

[mkeintz]

The WHERE statement can be regarded as "compile time" because WHERE (unlike IF) outsources the filtering to the data engine.  That engine might be a sas dataset engine, or (say) a foreign engine, but the logic of the filter is entirely outside of the DATA step statements.   

Among other consequences, this means

1. In the data step, the observations that fail the filter are never assigned an _N_ value.  I.e. they are not counted as observations processed.   The same filtering logic in an IF statement does count those obs.  Just try processing SASHELP.CLASS, once with WHERE SEX='F', and once with IF SEX='F';
   
   
2. The WHERE statement can be used with any other PROC.  The IF statement can't.  Great if you want to run, say, a regression on a particular subset of data - no need for a DATA step prior to the PROC REG.

So while KEEP and DROP can be thought of as compile time because they clearly don't impact the programming logic, the WHERE is a bit more active, but is still not part of the DATA step logic.  It is not "compiled" into the underlying DATA step code.