Hi,
Taking it in parts:
@novinosrin wrote:
Yes, that's a better way to describe it. The docs says
1. "Although the Null statement performs no action, it is an executable statement. Therefore, a label can precede the Null statement, or you can use it in conditional processing."[ examples to understand this statement in a meaningful is wanted ]
I think you already had an example of null statement being useful in conditional processing. For example, I might code:
if unit='inches' then height=height*2.54 ;
else if unit='cm' then ; *do nothing cuz already in cm ;
else put "ER" "ROR: (USER) " "unexpected unit!" unit= ;
That second statement works because SAS doesn't mind a null statement. I suppose if SAS didn't accept a null statement I could do something like:
if unit='inches' then height=height*2.54 ;
else if unit='cm' then do ; end ; *do nothing cuz already in cm ;
else put "ER" "ROR: (USER) " "bad unit!" unit= ;
So that has any empty do block with no statements in it, but is not actually a null statement (as per documentation; they may very well compile to the same byte code).
As for labels, if you look in the documentation on label: statement, it has more examples. I don't use the label statement much (ever?) in DATA step, but consider:
*list the female students ;
data want ;
set sashelp.class ;
if sex='M' then goto end;
put (name sex)(=) ;
end: ; *null statement;
run ;
The docs say END: is a label pointing to a null statement. The docs say that the label: statement needs to point to a statement and end with a semicolon (like any other statement), so allowing a null statement before the semicolon is useful. Allowing a null statement avoids the need to do something silly like:
*list the female students ;
data want ;
set sashelp.class ;
if sex='M' then goto end;
put (name sex)(=) ;
end: foo=1; *non-null statement;
run ;
That said, below code works (perhaps the label points to the RUN statement?):
data want ;
set sashelp.class ;
if sex='M' then goto end;
put (name sex)(=) ;
end:
run ;
And so does the below, which doesn't have a statement after the label (other than an implied run):
data want ;
set sashelp.class ;
if sex='M' then goto end;
put (name sex)(=) ;
end:
data foo ;
run ;
2. "The Null statement is useful while you are developing a program"[ The one example in the docs seems very inadequate to me]
I can imagine it might feel more useful if GOTO was more popular. As in the example, you could have some rare condition you don't want to handle yet, and say:
data want ;
set have ;
if condition then goto handler ;
return ;
handler: ;
run ;
And you could write the handler section later. I've never wanted to do that, but I think that's the case they're making.
Or I suppose with the conditional example, could code:
if x=1 then y=1 ;
else if x=2 then y=22 ;
else if x=3 then /*do not know what to do yet, fill me in later*/ ;
else put "ERROR: bad value";
I don't know if there is too much to worry about in the tokenization of a null statement. But I agree, the concept of a compiled/executable null statement in a data step would have a different "meaning" then a null statement in open code or proc step where it is interpreted rather than compiled.
Within the BASE SAS language, I've never seen a null statement cause a problem or anything interesting of note. Well, here's one. I suppose a null statement can "break" a code block, but that seems fair:
54 data _null_ ;
55 if sex='M' then foo=1;
56 ;
57 else if sex='F' then foo=2;
----
160
ERROR 160-185: No matching IF-THEN clause.
58 run ;
NOTE: The SAS System stopped processing this step because of errors.
I suppose that is evidence that the data step compiler does not simply skip null statements, it sees them enough to break compilation.
In the macro language, a null SAS language statement can cause problems, as discussed.
Kind Regards,
--Q.
The Boston Area SAS Users Group is hosting
free webinars!
Next webinar will be in January 2025. Until then, check out our archives:
https://www.basug.org/videos. And be sure to subscribe to our our email list.
