Folks:

This is an informal request to SAS-L for thoughts on a nested comment mechanism. I.e. if the next sasware ballot included an item like "introduce nested comments", how might the feature look in practice?

JUSTIFICATION:

AFAIK, SAS does not support nested comments. In particular a single "*/" cancels the effect of any number of preceding unpaired "/*" delimiters.

I for one would appreciate the ability to nest comments. When developing, say, a 7-step program I may have steps 3 and 5 already vetted and each therefore commented out via "/* ... */". If, after further testing, I want to comment out steps 2 through 6, I can't simply insert delimiters before step 2 and after step 6.

PROPOSAL:

Add //* and *// as nested comment delimiters, such that:

//* Increases the comment level by 1 *// Decreases the comment level by 1

EXAMPLE: using the 7-step program mentioned above, I start out with steps 3 and 5 commented with the proposed tokens.

... step 1 SAS code ... ... step 2 SAS code ... //* ... step 3 SAS code ... treated as a comment (level 1) *// ... step 4 SAS code ... //* ... step 5 SAS code ... treated as a comment (level 1) *// ... step 6 SAS code ... ... step 7 SAS code ...

Subsequently I want to comment steps 2 through 6. I would add //* before step 2 and *// after step 6:

... step 1 SAS code ... //* ... step 2 SAS code ... treated as a comment (level 1) //* ... step 3 SAS code ... treated as a comment (level 2) *// ... step 4 SAS code ... treated as a comment (level 1) //* ... step 5 SAS code ... treated as a comment (level 2) *// ... step 6 SAS code ... treated as a comment (level 1) *// ... step 7 SAS code ...

CONSIDERATIONS: 1. This feature should not be allowed to break the behavior of /* and */. In particular all comment levels established by //* would be subordinate to the effect of */, which would terminate all levels.

2. I know of no usage of the token "//*" in current SAS programs, and an unpaired "*//" would be treated the same as an unpaired "*/". So IMO these particular tokens are highly unlikely to be present in current programs. I.e. they shouldn't break any current code.

(Ahem) Comments?

regards, Mark