Hi,
Let me clarify then. What are lists, they are a series of data elements separated by delimiters. That descriptor in itself is enough to promote use of datasets, which are designed to handle data. This datastep programming has functions, strcutures and such like to deal with data, very few of which are to be found in macro programming. For instance all numeric data types, lists (or arrays as they could also be called). So lets take your first example. If I want to find all values from a given list, I would do it like this:
data list;
list=1453; output;
list=7987; output;
run;
proc sql;
create table WANT as
select *
from HAVE
where CODE in (select LIST from LIST);
quit;
You will note its a straight forward subquery, nothing is hidden, you don't need to look at log output to see what code is generated, it is plain code and anyone who knows SAS should understand the above. One of the other benefits to this method is if you have to further processing. Say for instance, I find that all list elements over 2000 actually need to have 500 removed from them. Just imagine the mess that macro code would become converting to numeric each element, checking, %eval()'ing etc. Whereas the simple code I provide above would just require one tiny update:
proc sql;
create table WANT as
select *
from HAVE
where CODE in (select case when LIST > 2000 then LIST-500 else LIST end from LIST);
quit;
That is the power of Base SAS, the ability to manipulate data quicky and efficiently, and allow complicated transformations across various structures.
In your second example, the datastep, you could of course use merging, which is another big power of Base SAS, or if you really want to have a list, then a simple symput from datastep can control that at the time the macro variable is needed.
Now nobody can say don't use macro, in much the same way as not to use Excel for data, as there is some really good functionality to be found within macro language, and code generation in general via many methods. However, that being said there does seem to be a consistent fallback position within SAS programming, in that "I can't seem to figure this out, lets jam it into macro", which creates a lot of unecessary and difficult to read code, which very often doesn't get documented or follow any form of development process. Take for instance the macro library, anyone who has started an new role will know what I am talking about. That area of code, built up of decades, very little documentation, held together by good will and more ampersands and percentage symbols than is proper. So often do I hear users talking about how they don't understand what these things do, or that they don't have XYZ functionality, or it doesn't do what is expected. It is ingrained that things have to be macro, personally my first question is always why, to which most of the time there is no answer, or the answer is because I couldn't do it in Base SAS - when at the end of the day, there is nothing which cannot be done in Base SAS, macro at the end of the day only generates Base SAS code.
So thats my standpoint in a nutshell, I prefer code to be as simple and visible as possible, even down to code formatting, anything to make the code simpler and easier to look at. So in terms of this:
"Understanding the generation of lists, and iteration over lists, and manipulation of lists is a critical skill to anyone learning the macro language."
To my mind learning Base SAS thoroughly, and be able to think about your data, how changing strucutures, and thinking about it in different ways, can lead to simpler solutions which are more robust and easier for end users to implement and manipulate.
End of opinionated long post, apologies original poster for sidetracking your thread.
