Would You Use a "Running Semicolon" Character?

[tc]

"Running Semicolon"

As HBO's Silicon Valley amusingly showed us, programmers can get into heated arguments over the use of Tabs vs. Spaces.

In the SAS world, debates can arise over whether every DATA step and PROC should be terminated with a RUN or QUIT statement - large SAS programs may include 100+ "RUN;" statements - many technically 'unnecessary' (depending on who you ask!) - making some SAS programmers happy while irritating others. So, a question for lovers and haters of the RUN-even-if-unnecessary rule: If a "running semicolon" or "RUN character" was available, would you be okay with the use of that? 👍👎

LOOK-MA-NO-SPECIAL-CHARACTERS

"RUNNING SEMICOLON CHARACTER"

"RUN CHARACTER"

[ChrisHemedinger]

@Rick_SAS shared his thoughts in "Do you write unnecessary SAS statements?"

@tc I think it's time to propose a new run; emoji to the Unicode consortium. The "running" emoji character is:

🏃	\u0001F3C3

But as you can see, it faces the wrong way. We want our SAS programs to run forward to the next statement. 

[tc]

So, this gave me an idea...could I create a Unicode macro like this?

Alas, there's no support for Unicode characters in variable names (yet!), but it looks like it may not be far off:

And the next logical step after Unicode macro names is image macro names, right? 😀

[AlanC]

Bad idea IMO.

Most SAS code I have to deal with is in ASCII vs Unicode. I don't think adds anything to the language and permeates bad habits. Every time I have to look at someone's code that is missing run statements, I find it irritating. It is a small piece of code that delineates a step boundary.   

Also, I think it would break a lot of stuff that is unforeseen. What? I don't know but I don't think it would be worth chancing. 

[tc]

Wondering if this is a preference that could be accommodated by an editor - store code in "raw ASCII" mode (LFCR-RUN;), but allow things to be displayed and edited in either raw or "rich text" (Unicode) mode, depending on users' options.

[ballardw]

Since we see entirely too many questions on the forum about data vs session encoding (Utf-8 vs wlatin vs Utf-16 vs <what ever national language set) already I cringe at the notion of hordes of Unicode "coding" symbols to complicate everyone's life.

It's bad enough dealing with the occasional need for "text output" AKA the Listing destination and using the SAS Monspace font to make pretty tables (until seen on a computer without that font) because Microsoft removed the very early standard box drawing characters from all the default fonts in Windows and seems to spread to other character sets. Every have a boss complain about boxes drawn with +-------------+ characters when required to have "text output"?

Today's code without a "run;" may get dropped into the middle of someone else's macro code tomorrow with obnoxious side effects. So I want to see Run; or Quit; not some character that may not even display.

[tc]

Someday in the not-too-distant-future, I think user-defined symbols/Unicode - and HTML/markdown, images, hyperlinks, sound, video, etc. - will be able to be used directly in statements and comments (not just in process flows or markdown cells in notebooks!) with most widely-used programming languages and will prove to be extremely helpful. With that being said, I guess smart people have been grappling with this kind of problem since the days of APL/360! 😀

IBM 2741 terminal keyboard with stickers applied to front of keys for APL symbols.

[ballardw]

For what it may be worth, the key board I am currently typing on is not the one supplied with the computer by HP because that one would not let me use the function keys for the actions the SAS display manager allows because it was set up with "browsing" in mind. To use the function keys, such as to move from Program window to Results I would have had to press two other keys and activate an alternate mode then press the function key. Every blinking time. So I replaced the keyboard with one that had a more standard result for pressing the function keys an allows those other behaviors as the alternate function key behavior.

[ChrisHemedinger]

Modern programming languages have supported Unicode characters as part of code for years. However since they are difficult to type (unless you have that overloaded keyboard mapping that @tc shared) they aren't really practical. It's more of an interesting poetic idea.

And while unescaped Unicode chars can't appear in your SAS code, you can use them as part of variable names if you want to make life difficult for the next person who needs to write code against your data.

data pi;
 'π'n = constant('pi');
run;

[Rick_SAS]

To clarify Chris's statements: SAS supports the use of Unicode as the content of strings or as an n-literal that specifies the name of a variable (column)  or symbol (in a program). But the SAS grammar does not support Unicode, which means that Unicode is not used for statements, options, or keywords in SAS procedures.

[tc]

Job security via emojis! 😊

But what I'm thinking of here for starters with the Unicode macro mockup show above really isn't much of a leap from the concept of circa-1980 mainframe ISPF attribute characters, which were used to define screen attributes (see below) and let one use a single character to represent a string of characters, which worked much better than one might imagine.

The main difference here is that the character would be Unicode not ASCII, and you could tap into the full power and flexibility of SAS's macro language. There is the special character/Unicode input problem, which has vexed people since the dawn of APL, but the use of keyboard shortcuts and MS-Word's Insert-Symbol feature comes to mind as possible solutions. I'd imagine we could also look to editors for languages other than English for even greater inspiration on how to crack the Insert-Symbol problem. 😊

ISPF Dialog Management Services - Sample Attribute Definition Section

[AlanC]

Similar to mathematics, programming doesnt need new symbols to express logic. SAS hasnt even adopted lambda functions.

Programming languages shouldnt have decoration: save that for places like Twitter.

[tc]

I still have hopes that someone will have a Eureka! moment on this and figure out good solutions for graphics and text to co-exist in code, although I'll concede that even the straightforward insert-special-character problem has vexed people since the dawn of APL 50+ years ago and that bad graphics solutions can indeed be worse and create more problems than no graphics solution at all. 😀

[SASKiwi]

@tc - Yep, back in the day I grappled with APL for a while. I soon realised it's a great way to write very compact and powerful programs that no one, even the author, could understand and support afterwards. Fortunately I was learning SAS at the same time. Guess which language won and is the one I continue to use to this day...

[Tom]

---

@SASKiwi wrote:

@tc - Yep, back in the day I grappled with APL for a while. I soon realised it's a great way to write very compact and powerful programs that no one, even the author, could understand and support afterwards. Fortunately I was learning SAS at the same time. Guess which language won and is the one I continue to use to this day...

---

But did you get a replacement ROM chip for your IBM PC Monochrome Monitor Adapter board so that you could see the APL character set on the screen?