Sometimes the SAS code interpreter assumes a typo, for example when I submit a tabels statement in Proc Freq, SAS gives a warning and runs a tables statement instead.
Many, if not most, programmers use one statement per line.
Some programmers, including me, sometimes forget one or more semicolons, for example after a * comment.
I would like to get some help here. If my submitted code ends up in errors or warnings, can the code interpreter add missing semicolons at the end of a line and then try again?
I did confirm with internal experts (so you know it's not just me) and I can say that this is not something we can consider for the programming language. However, we're always working to make SAS programming easier for new users -- keep those ideas coming!
I can understand the frustration. There have been countless times where I've debugged code, in SAS and other languages, only to realize the error was simply a semicolon. It's frustrating to see the "ERROR 180-322: Statement is not valid or it is used out of proper order." which doesn't sound like it's all about semicolons.
That said, I don't want anybody to modify my code, including the IDE or interpreter. And if I have a multiline statement that throws an error, I don't want semicolons to break it. For example, if I'm adding a number of variables together, and the expression covers multiple lines.
It boils down to, how will the environment know where to impute semicolons? Yes, it's frustrating that sometimes more time than we'd like is spent debugging that only reveals one tiny character, but I'd rather have that then a system which (frustratingly) adds semicolons in a "smart" way.
I'd like to hear others' thoughts on this.
Since the semicolon is a STATEMENT ender and not a LINE ender I really do not think this is appropriate. I have had more than one program where I have a list of values that extends across several lines, such as using an IN operator against phrases , values in a custom format or ODS Text that extend across multiple lines where an inserted semicolon would be 1) incorrect at minimum and 2) generate a bunch of other errors at worst.
I have used other programming language where you had to explicitly indicate a line of code was a continuation of the previous by inserting either a special character/combination OR in a specific column and would really prefer not to have that any more since I am no longer coding using a keypunch machine on cards.
I have to agree with @ballardw and @paulkaefer. SAS is one of those languages where the semicolon is the statement delimiter. Other languages include C, Java, C++, C#, PL/1, and many many others that have a rich heritage. No C programmer would suggest that a semicolon should be optional.
Some languages use a different approach. Visual Basic uses the line ending to indicate the end of a statement (with a special "line continuation" cue - the underscore - if you want a statement to span multiple lines). Python uses indenting to indicate nested logical structures. These languages don't need the semicolon to do that job because they have other well-defined rules to serve the purpose.
Don't expect SAS to infer a semicolon when you forget one (and we all do that!). If we weren't so strict about the semicolon, then many constructs would be ambigious -- and ambiguity has no place in a programming language!
Thanks for your thoughts!
I guess I should not have called myself a programmer
Maybe the "user" or "analyst" (or whatever) in me would like to be directed quicker to the real error. Like paulkaefer said not all SAS Error messages are specific enough. This also applies to unequal numbers of left and right brackets.
I also recognize the product-oriented replies regarding the role of a semicolon, but maybe a more customer (that's me!) centric approach would help here. Like "Hey Eric, maybe adding a semicolon here would help since the code without it doesn't compile and the same code with this semicolon does".
Does this need a new suggestion?
Hi @EH, as a person new to SAS and not (yet) comfortable with programming, you might benefit from using one of our more visual code-building tools, such as SAS Enterprise Guide or even the tasks in SAS Studio. We have many SAS Enterprise Guide users who accomplish their work without writing a single line of SAS code. And if/when you want to learn the code, you can use the generated programs that the tool produces as a starting point.
We also have many tutorials and self-paced e-learning courses that can help. The tutorials are free, and some of the beginning courses are also free. With practice, you'll get over this initial hump -- I promise.
I will try. Thanks for the replies.
I was hesitating to finish my reply like I do below :-)
(SAS user since 1987)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.