Recommend also borrowing from MUMPS

[markbej]

I have not used MUMPS apart from a brief stint in the late 1980s.
They had several interesting if not strange quirks compared to other programming languages, but of which I will touch on only 2.

(1) Command Abbreviation.
Because it was (then, at least) an interpreted language, to make processing more efficient, they allowed ANY type of abbreviation of ANY command to ANY number of letters, so long as the abbreviation was distinguishable from other commands. Thus, "QUIT" could be that, or "QUI", or "QU", or, most commonly, "Q".

(2) Significant whitespace.
All statements HAD to be <parameter(s)> . But the Quit statement (and others? don't recall) had no parameters they could take. Regardless, the absence of parameters had to be explicitly stated as such by including TWO space characters after "Q". lest the program/script fail. QUIT was used similarly to a close-brace } in C-like languages, so it could be used in the middle of a line with additional statements (commands) following it. Needless to say, not having 2 spaces after a Q resulted in errors.
As I recall, they did NOT require the spaces at end of line, but I would certainly encourage BS to require such on every single statement of code. (In other words, make the space character a postfix grammatical operator, rather than an infix grammatical operator.) Of course, similarly to tabs vs. spaces at the start of a line of code, the presence or absence of said spaces would not be immediately visible to the user. Only by visiting the line and hitting the "End" key would the absence of the space character be discovered.

(2a) Insignificant whitespace.
In FORTRAN, DO10I=1 set a variable, whereas DO10I=1,2 was a statement (which no doubt confused continental Europeans who prefer commas as the decimal marker). BS could potentially allow for whitespace to be insignificant only in certain locations such as variable names.

(3) Line continuation character.
Shouldn't this absolutely amazing feature of FORTRAN/Fortran be borrowed by BS? Because Algol/Pascal/C-style implicit line continuation is just too intuitive and easy. Perhaps line continuation could be indicated by a TAB character at the end of a line (after any required space from the above characters, of course) ...

(4) Statement-ending character.
This is, of course, just a version of the war of the period (full stop) vs. semi-colon vs. nothing. However, in the spirit of PL/I, we should not be either/or, but rather both/and. Because we want to be inclusive! My recommendation is to use the period as a statement-ending character for those statements that start with a verb or verb-like word (DO, LOOP, etc.), even if they are implicit (LET). However, statements that are non-verb-like would require a semicolon, rather than a period (declarations, which are an implicit DECLARE anyway). Finally, those statements that start a block would end with a single colon. In all cases, one would have to keep line-ending characters in mind as well.
The presence of statement-ending characters should not in any way, of course, negate the requirement for line-continuation characters as mentioned above.

(5) Explicit identification of data.
This is from Lisp, of course. There is a reason for Lisp to have this feature (and require its explicit use). Unfortunately, it is also a source of programmer errors and thus frustration when inadvertently missed. Why not include it in BS, then? Since the single- and double-quote are already taken for other purposes, let's use the (single) back-quote. The added confusion versus the back-quote's meaning in Unix is just an added bonus. Thus, one would be forced to write
LET pi=3.1415927 to identify the 3.1415927 token as being an item of data, rather than a variable name. This clarification of what precisely is data leads immediately to the next potential candidate for inclusion into BS, which is variable names consisting of numbers. Thus, BS would recognize this as a valid statement: LET 3.1415927=3.14
(where 3.1415927 is a variable name, and the ` identifies 3.14 as data). Both programmers and users will be confused the user as to the source for the lack of precision. (This is akin to what some Fortran IV compilers used to allow thanks to call by reference.) Moreover, BS could allow the following as well:
LET 314.15927E02='3.14

(6) Case sensitivity.
Some version of the MS-DOS vs. Unix case (in)sensitivity wars would be fun and interesting to throw in. And of course, only certain things should be case-sensitive, and others case-insensitive, with the decision on this made to allow for maximum confusion and promotion of programmer errors.

(7) Mathematical operators.
Mathematical operators make things too easy. Let's combine COBOL's wordiness with Lisp's non-infix notation for math. Something like
LET €hyp = SQRT(€base2 + €side2)
is just too obvious. And since Lisp is pre-fix, we should probably go with post-fix just to be different:
LET €hyp = ((((€base, 2, Power) Push) (€side, 2, Power) Add) Sqrt)
would just add to the difficulty of reading and maintaining the code. Hurray for 1980s-90s HP calculators! Also, the assignment operation could be viewed as a function, like Lisp does, to yield
(€hyp ((((€base, 2, Power) Push) (€side, 2, Power) Add) SquareRoot) LET)
Note that all-caps LET is that way exactly because it COULD be a statement-starting keyword (DO, WHILE, etc.) (even though as in the last case it may not actually do so), whereas Add, Sqrt, Power are only caps-initial because, although keywords, they could never start a statement.

(8) Some keywords in BS should be two or even three or four words long, similarly to certain keywords in SQL. "fi" or "endif" is just insufficiently fun.

--
Mark Bej
mbej@nomshealthcare.com