Hokey (The Moderator) <hokey@plus5.uucp> (03/12/85)
std-mumps Digest Tue, 12 Feb 85 Volume 1 : Issue 11
Today's Topics:
By the way...
Mumps...
----------------------------------------------------------------------
Date: Mon, 11 Mar 85 14:48:27 cst
From: ihnp4!umn-cs!ncs-med!bi (Bob Isch)
Subject: By the way...
To: umn-cs!ihnp4!plus5!std-mumps
I was just glancing at the new definition of _line_ (right after I sent
the last note) and noticed something interesting. If _ls_ is multiple
spaces now why is there an optional _cs_ in front of _comment_?
One other comment on _line_, I never understood why the _cs_ was
optional before a _comment_. This just seems inconsistant with everything
else requiring space before it. In fact, this implies that:
q;_comment_
q ;_comment_
should work. In addition to:
s a=b;_comment_
which does not work under certain Major implementations that claim
to be Ansi standard.
I say pull the whole thing out and require one or more space.
Again, refer to the definition of _line_ in my Structured Mumps
proposal. -bi
------------------------------
Date: Mon, 11 Mar 85 14:36:50 cst
From: ihnp4!umn-cs!ncs-med!bi (Bob Isch)
Subject: Mumps...
To: umn-cs!ihnp4!plus5!std-mumps
Re: $piece:
Thinking about this makes my head hurt, anyone who uses naked references
across = is in for trouble anyway. However, you might be able to get
a more contorted example by using global references inside the the
subscripts on the left hand side expression.
Re: lines and $text.
Actually, I think the fix is to simply define $text as returning the
whole line regardless of the definition of ls. The standard used to
define:
ls ::= SP
Now I assume it defines:
ls ::= SP [ SP ... ]
So, just take the clause that says _ls_ is replaced by one SP out of
the $text definition. I always was a little uncomfortable with needing
to define _ls_ anyway. It always seemed like something funny going on
because some implementations like to use TAB there.
Related to the _line_ discussion, what I really think should be done
is to use the definition of _line_ in my structured mumps proposal
(of course *I* would say that).
In any case, I have enclosed below the latest copy of the proposal.
Why don't you put it in the next posting to std-mumps and see if
we can get any feedback.
--------------------------- Proposal ---------------------------------
To: Mumps Development Committee and other
Parties interested in Mumps Block Structuring
From: Bob Isch 17 August 1984
National Computer Systems
Medical Systems Division
5700 Green Circle Drive
Minnetonka, MN 55343
(612) 893-8137 ihnp4!umn-cs!ncs-med!bi
rev 0.0 (30Nov83)
rev 0.1 (14Jan84)
rev 0.2a(24Apr84)
rev 1.0 (17Aug84)
ncsmed/us/bi/mdcprop/cover
ncsmed/us/bi/mdcprop/main
Re: Mumps Block Structuring Proposal
Enclosed is a proposal for extending the control structures
provided by the Mumps language. This proposal is based on
a proposal submitted to the MDC prior to its last meeting
in June 1984. The changes made here reflect some of the
discussion and issues raised at that meeting. Any comments
or suggestions would be greatly appreciated. These can be
sent to my attention at the above address, phone number, or
UseNet address.
encl.
Mumps Language Proposal
Control Structures
ncsmed/us/bi/mdcprop/prop
This proposal describes changes to the draft ANSI X11.1 - 1983
standard to extend the control structures provided by the Mumps
language.
The primary motivation for adding control structures, such as
those described here, to the Mumps language is to provide the
programmer with a better tool for representing program logic flow
in Mumps. The limitation of the scope for the IF, ELSE, and FOR
commands imposed by the current standard is often cumbersome,
resulting in exceedingly long Mumps lines and/or unnecessary
labels and subroutines. Further, there are several problems com-
monly encountered because of the relationship between the IF and
ELSE commands and the $TEST special variable. None-the-less,
there is a need to be upward compatible with the current defini-
tion of Mumps.
This proposal addresses these problems in a simple and straight
forward manner drawing on approaches of languages whose popular-
ity is often claimed to be based on their having such features
(e.g. Pascal, C, etc.).
The basic approach is to use the curly braces "{" and "}" to del-
imit blocks of code thus forming compound statements that can be
used as the scope of an IF, ELSE, or FOR command. Note, however,
that almost any other character or character sequence(s) could be
used in place of curly braces. The standard could specify one or
more alternatives.
IF, ELSE, and FOR commands will have the traditional scope of the
rest of the line if compound statements are not used. If a com-
pound statement is used, the scope of the IF, ELSE, or FOR will
only be up to the closing curly brace "}" that terminates the
compound statement. Note that if an IF, ELSE, or FOR that does
not use a compound statement occurs within a compound statement
then the scope of the enclosed IF, ELSE, or FOR terminates at the
closing curly brace "}" that terminates the compound statement.
Compound statements can start only immediately following an IF,
ELSE or FOR and must terminate on the same line.
The effect of using such a compound statement with an IF, or
ELSE, or FOR is purely related to flow control. No interaction
with subroutine nesting levels or variable scoping ranges (e.g.
the QUIT or NEW command) takes place.
The problem of the $TEST variable not being stacked is solved by
by ensuring that the value of $TEST is always 1 when falling out
of a compound statement associated with an IF command and always
0 when falling out of a compound statement associated with an
ELSE command. This allows IF ELSE-IF ELSE combinations to work
intuitively simply by making the statements scoped by the IF com-
mands into a compound statement. Note that the $TEST variable is
not stacked in this instance, instead the value of $TEST is
guaranteed at the end of the compound statement. Neither are the
statement blocks in these instances considered activation blocks
(they have no effect on parameters or name scoping). $TEST is
not affected when falling out of a compound statement that is the
scope of a FOR.
Other Notes:
Again, note that use of curly braces in this proposal is strictly
syntactical. These could be substituted with just about any
sequence of characters.
One interesting alternative or extension to the curly braces
would use different block boundary characters for the different
types of blocks (e.g. "{i", "i}", "{e", "e}", "{f", "f}"). This
would allow the Mumps processor to do some additional semantic
checking for the programmer.
Since the syntax of the ELSE command now encompasses the state-
ments comprising its scope it would be possible to consider
relaxing the requirement of having two spaces following the com-
mand name. This would serve no other purpose than simplifying
the coding process.
The reworking of the line syntax seems to evoke two additional
changes that seem reasonable. First, trailing spaces are allowed
on any Mumps line. Second, any number of spaces are allowed
before the first command on the line.
Attachments:
The following page contains some examples of Mumps code using
this proposal.
Following the examples are the changes to sections 3.4, 3.6.9,
3.6.4, and 3.6.5 of the standard necessary to carry out this pro-
posal.
Examples:
---
I A=B { S C=D D FOO } ELSE S C=0
---
F I=1:1 I I>X { S Y=X,X=I Q } S J=I/X
---
IF A>B { S A=B D FOO }
ELSE IF A<B { S B=A D FOO }
ELSE { S A=0 IF B>5 { D FOO1 S A=B } ELSE D FOO2 }
---
IF A=B { W A } ELSE { W B }
---
X "IF A=B { D FOO W A } ELSE { F I=1:1:9 W I } S C=D"
---
ncsmed/us/bi/mdcprop/line
3.4 Routines
The routine is the unit of program interchange. In program
interchange, each routine begins with its routinehead, which con-
tains the identifying routinename, and the routinehead is fol-
lowed by the routinebody, which contains the executed code. The
routinehead is not part of the executed code.
routine ::= routinehead routinebody
routinehead ::= routinename eol
routinename ::= name
The routinebody is a sequence of lines terminated by the eor.
Each line ends with eol, starts with ls optionally preceded by a
label, and may contain zero or more commands (separated by one or
more spaces) between ls and eol. Any line may end with a comment
immediately preceding the eol. Zero or more spaces may separate
the comment from the last command of the line.
routinebody ::= [ line ]... eor
linebeg ::= [ label ]
linebegmid ::= linebeg [ ls commands ]
linemid ::= [ cs commands ]
lineend ::= [ cs [ comment ] ] eol
line ::= linebegmid lineend
label ::= | name |
| intlit |
commands ::= command [ cs command ]...
ls ::= SP [ SP ]... ( one or more spaces at
start of line)
cs ::= SP [ SP ]... ( one or more spaces)
eol ::= CR LF ( two control characters )
eor ::= CR FF ( two control characters )
ncsmed/us/bi/mdcprop/if
3.6.9 IF
| [ SP ] |
I[F] | |
| SP [ L ifargument ] stmtblk |
ifargument ::= | tvexpr |
| @ expratom V L ifargument |
stmtblk ::= | sstmtblk |
| bstmtblk |
sstmtblk ::= linemid
bstmtblk ::= cs { linemid cs }
In its argumentless form, IF is the inverse of an argumentless
ELSE. That is, if the value of $T is 0, the stmtblk is not exe-
cuted. If the value of $T is 1, execution continues at the next
command within stmtblk.
If exactly one argument is present, the value of tvexpr is placed
into $T; then the function described above is performed.
IF with n arguments is equivalent in execution to n IFs, each
with one argument, with the respective arguments in the same
order. This may be thought of as an implied "and" of the condi-
tions expressed by the arguments.
If stmtblk is a bstmtblk and $T is true after evaluation of the
ifargument(s) execution resumes at the point immediately follow-
ing the "{" of the bstmtblk. When execution encounters the "}"
of the bstmtblk $T is set to 1 and execution continues at the
point immediately following the "}".
ncsmed/us/bi/mdcprop/else
3.6.4 ELSE
E[LSE] [ SP stmtblk ]
If the value of $T is 1, the stmtblk is not executed. If the
value of $T is 0, execution continues normally at the next com-
mand within stmtblk.
stmtblk is as defined for the IF command.
If stmtblk is a bstmtblk and $T is 0, execution resumes at the
point immediately following the "{" of the bstmtblk. When execu-
tion encounters the "}" of the bstmtblk, $T is set to 0 and exe-
cution continues at the the point immediately following the "}".
ncsmed/us/bi/mdcprop/for
3.6.5 FOR
F[OR] SP lvn = L forparameter [ fstmtblk ]
| expr1 |
forparameter ::= | numexpr1 : numexpr2 : numexpr3 |
| numexpr1 : numexpr2 |
fstmtblk ::= stmtblk
The "scope" of the FOR command consists of the commands within
the stmtblk.
FOR specifies repeated execution of its scope for different
values of the local variable lvn, under successive control of the
forparameters, from left to right. Any expressions occurring in
lvn, such as might occur in subscripts or indirection, are
evaluated once per execution of the FOR, prior to the first exe-
cution of any forparameter.
For each forparameter, control of the execution of the scope is
specified as follows. (Note A, B, and C are hidden temporaries.)
a. If the forparameter is of the form expr1.
...
b. ...
...
c. ...
...
d. ...
...
Note that form d. specifies an endless loop. Termination of this
loop must occur by execution of a QUIT or GOTO within the scope
of the FOR. These two termination methods are available within
the scope of a FOR independent of the form of forparameter
currently in control of the execution of the scope; they are
described below. Note also that no forparameter to the right of
one of form d. can be executed.
Note that if the scope of a FOR (the "outer" FOR) contains an
"inner" FOR, one execution of the scope of the outer FOR
encompasses all executions of the scope of the inner FOR
corresponding to one complete pass through the inner FOR's for-
parameter list.
Execution of a QUIT within the scope of a FOR has two effects.
a. It terminates that particular execution of the scope at
the QUIT; commands following the QUIT within the same
fstmtblk are not executed.
b. It causes any remaining values of the forparameter in
control at the time of execution of the QUIT, and the
remainder of the forparameters in the same forparameter
list, not to be calculated and the scope not to be exe-
cuted under their control.
In other words, execution of a QUIT effects the immediate termi-
nation of the innermost FOR whose scope contains the QUIT.
Execution of GOTO effects the immediate termination of all FORs
in the line containing the GOTO, and it transfers execution con-
trol to the point specified.
------------------------------
End of std-mumps Digest
******************************
--
Hokey ..ihnp4!plus5!hokey
314-725-9492