hokey@plus5.uucp (The Moderator) (05/02/85)
std-mumps Digest Thu, 2 May 85 Volume 1 : Issue 14
Today's Topics:
"JOB" PROPOSAL - JACK BOWIE - 5/2/85
FIGURE ONE - JACK BOWIE - 5/2/85
MUMPS COVER LETTER FROM JACK BOWIE - 5/2/85
PARAMETER PASSING - JACK BOWIE - 5/2/85
Routine Structure - Jack Bowie - 5/2/85
----------------------------------------------------------------------
Date: Thursday, 2 May 1985 08:24:27-PDT
From: nimbus.DEC!gallagher (Donna M. Gallagher MRO3-2/H7 DTN: 231-2372)
Subject: "JOB" PROPOSAL - JACK BOWIE - 5/2/85
To: seismo.uucp!plus5!std-mumps, gallagher%nimbus.DEC
Job Command Extension Proposal
Section 3.6.9.5
3.6.9.5 JOB
J[OB] postcond L jobargument
entryref [ : jobparameters ]
jobargument ::= labelref jobactuallist [ :jobparameters ]
@ expratom V L jobargument
jobactuallist ::= (L expr)
processparameters [ timeout ]
jobparameters ::=
timeout
expr
processparameters ::=
( [ [ expr ] : ] ... expr )
For each jobargument, the JOB command attempts to initiate
another MUMPS process. If the jobactuallist is present in a
jobargument, the line designated by the labelref must contain
a formallist in which the number of names is greater than or
equal to the number of exprs in the jobactuallist.
The JOB command initiates this MUMPS process at the line
specified by the entryref or labelref. If the jobactuallist
is present, the process will have certain variables initially
defined. These variables will be taken from the formallist
of the line designated by the labelref. Formallist names
will be created and paired with the values of the
jobactuallist exprs for as many exprs as are present in the
jobactuallist. If the jobactuallist is not present, the
process will have no variables initially defined. The
processparameters can be used in an implementation-specific
fashion to indicate partition size, principal device, and the
like.
If a timeout is present, the condition reported by $T is the
success of initiating the process. If no timeout is present,
the value of $T is not changed, and process execution is
suspended until the MUMPS process named in the jobargument is
successfully initiated. The meaning of success in either
context is defined by the implementation.
------------------------------
Date: Thursday, 2 May 1985 08:20:48-PDT
From: nimbus.DEC!gallagher (Donna M. Gallagher MRO3-2/H7 DTN: 231-2372)
Subject: FIGURE ONE - JACK BOWIE - 5/2/85
To: seismo.uucp!plus5!std-mumps, gallagher%nimbus.DEC
New Figure 1
Name Table Value Table
___________ _______________
| name | | VID |RfC|
| VID | | value |
|=========| | subs. pairs |
| ABC | |=============|
| 714 |--------------->| 714 | 1 |
|=========| | "HELLO" |
| XYZ | |=============|
| 86 |--------------->| 86 | 2 |
|=========| | undefined |
| BUF | |=============|
| 193 |--------------->| 193 | 1 |
|=========| | "ARRAY" |
| 1 |
+-----| 203 |
| | 2 |
| +--| 230 |
| | |=============|
| +->| 230 | 1 |
| | "JONES" |
| |=============|
+---->| 203 | 1 |
| undefined |
| "NUM" |
+--| 404 |
| |=============|
+->| 404 | 1 |
| "1234.5" |
|=============|
Variable Name VID Data Value $DATA
ABC 714 "HELLO" 1
XYZ 86 undefined 0
BUF 193 "ARRAY" 11
BUF(1) 203 undefined 10
BUF(2) 230 "JONES" 1
BUF(1,"NUM") 404 1234.5 1
Figure 1
------------------------------
Date: Thursday, 2 May 1985 08:16:30-PDT
From: nimbus.DEC!gallagher (Donna M. Gallagher MRO3-2/H7 DTN: 231-2372)
Subject: MUMPS COVER LETTER FROM JACK BOWIE - 5/2/85
To: seismo.uucp!plus5!std-mumps, gallagher%nimbus.DEC
*****************
* d i g i t a l * INTEROFFICE MEMORANDUM
*****************
TO: MUMPS Development Committee DATE: 30-Apr-85
FROM: Jack Bowie
DEPT: MSG Engineering
EXT: 231-2361
LOC/MAIL STOP: MRO3-2/H7
SUBJECT: MUMPS Proposal
Find enclosed three proposals as requested at the November MDC
meeting. The first proposal attempts to tie together all the
parameter passing, extrinsic functions, etc. ideas around a new
definition of variable handling. No new functionality has been
added. One editorial change was made, the substitution of dlabel
for label in lineref.
The second proposal is an extension of the JOB command permitting
the transfer of values to the invoked routine. The proposed
syntax parallels that for parameter passing.
The final proposal is a rewrite of the block structuring proposal
which has been tentatively accepted by the committee. The
proposal has been made based on the parameter passing revisions
described above.
Please review these proposals carefully. I hope we can come to a
resolution at the June meeting.
See you in Chicago!
------------------------------
Date: Thursday, 2 May 1985 10:48:48-PDT
From: nimbus.DEC!gallagher (Donna M. Gallagher MRO3-2/H7 DTN: 231-2372)
Subject: PARAMETER PASSING - JACK BOWIE - 5/2/85
To: seismo.uucp!plus5!std-mumps, gallagher%nimbus.DEC
Table of Contents - Part I
. . .
1.2.1 Character Set
1.2.2 Routine Structure
1.2.3 Program Punctuation
1.2.4 Data Types
1.2.5 Precedence of Operations
1.2.6 Commands
1.2.7 Intrinsic Functions
1.2.8 Intrinsic Special Variables
1.2.9 Extrinsic Functions
1.2.10 Extrinsic Special Variables
. . .
3.2.7 Intrinsic Special Variables
3.2.8 Intrinsic Functions
. . .
3.2.10 Extrinsic Special Variables
3.2.11 Extrinsic Functions
. . .
3.5.1 Post Conditionals
3.5.2 Spaces in Commands
3.5.3 Comments
3.5.4 format in READ and WRITE
3.5.5 Side effects on $X and $Y
3.5.6 Timeout
3.5.7 Line References
3.5.8 Command Argument Indirection
3.5.9 Parameter Passing
Section 1.1 Line 4
change the line to read
.... Section 3 describes the static syntax and overall
semantics of the language....
Section 1.2.2 add at end:
Labels may have associated formal parameter lists.
Parameters passed to routines may be either call-by-value
or call-by-reference.
Section 1.2.7 Intrinsic Functions
The following intrinsic functions are currently specified.
. . .
Section 1.2.8 Intrinsic Special Variables
The following intrinsic special variables are specified.
. . .
Section 1.2.9 Extrinsic Functions
MUMPS routines may be invoked to return values as
extrinsic functions.
Section 1.2.10 Extrinsic Special Variables
MUMPS routines may be invoked to return values as
extrinsic special variables.
Section 3 Heading
change to:
3. Static Syntax and Semantics
Section 3.2 Expression Atom expratom
. . .
svn
exvar
function
exfunc
expritem ::=
numlit
strlit
(expr)
unaryop expratom
Section 3.2.2 Paragraph 3
Replace this paragraph with:
MUMPS uses the term local variable to denote variables
that are created for use during a single process
activation. These variables are not available to other
processes. However, they are generally available to all
routines executed within the process's lifetime. MUMPS
includes certain constructs, the NEW command and parameter
passing, which limit the availability of certain variables
to specific routines or parts of routines. See Section
3.2.2.3 for a discussion of these variable environments.
Section 3.2.2.3 (New Section)
3.2.2.3 The Variable Model
The association of MUMPS variables with their values can
best be described by a conceptual model. This model
addresses the dynamic relationship between variable
environments and MUMPS control structures. The model is
not meant to imply an implementation technique for a MUMPS
processor.
The value of a MUMPS variable may be described by a
relationship between two tables, the Name Table and the
Value Table. (In reality at least two such table sets are
required, one for process-specific local variables and one
for system-wide global variables. Since the value
association process is the same for both types of
variables, and since issues of scoping due to parameter
passing or nested environments apply only to local
variables, the discussion that follows will address only
local variable value association.)
The Name Table contains the name portion of all (local)
variables "known" at any one time during the process
lifetime. A given name occurs only once in the Table.
The Name Table is composed of a set of entries, each of
which consists of the identifying name and a Value ID
(VID). The VID is an identifier which "points" to an
entry in the Value Table. VID's are generated
sequentially as needed and are unique within the lifetime
of the process.
The Value Table contains the values of all (local)
variables for the process. Value Table entries consist of
the identifying VID, a reference count, a data value and,
optionally, a set of subscript pairs. The reference count
keeps track of multiple bindings to the value due to
parameter passing. The data value is the value of the
(variable) name "pointing" to this entry. A special
"undefined" symbol may replace the data value. The
subscript pairs identify additional "descendant"
variables. The Value Table entry pointed to by a Name
Table entry contains the value of the unsubscripted name
variable (which may be the undefined symbol) and the set
of values defined in the first subscript position. The
subscript pairs are these subscript values and their
associated VIDs. Each of these VIDs, in turn, point to
additional Value Table entries which contain the value of
the (subscripted) variable and possibly further subscript
pairs. Thus there can be a linked, hierarchical,
relationship of Value Table entries originating from a
single Name Table entry. Each of the variables
represented by the set of subscript pairs in a Value Table
entry are called "descendants" of the variable name which
"pointed" to the entry (via its VID). Formally, an
M-tuply subscripted variable N(v1,v2,...,Vm) with name N,
subscript values v1, v2,...,vm, and m greater than zero,
is a descendant of any n-tuply subscripted variable N(v1,
v2,...Vn) for all n<m having the same N and identical
values for v1 through Vn. (This includes the case n=0,
i.e. A(3) is a descendant of A).
At the initiation of the process, both the Name Table and
the Value Table are empty.
Figure One graphically describes the Name Table and Value
Table relationship for a number of variables. It also
shows the specific VIDs, values, and $DATA values for
these variables. (See Section 3.2.8 for a description of
the $DATA function).
When the value of a variable is required, the Name Table
is searched for an entry containing the name portion
specified variable name. If the name is not found, the
value is said to be undefined. If the name is found, the
Value Table is searched for the entry containing the VID
that was associated with the name. If the variable is
unsubscripted, the data value in this Value Table entry
(which may be this "undefined" symbol) is returned as the
value of the variable. Otherwise, the subscript pairs are
searched for a pair whose value matches the first
subscript value in the variable name. If no such match is
found, the value is undefined. If a match is found, the
VID of the pair is taken and the above search procedure is
repeated on the Value Table entry pointed to by this VID.
The procedure is performed for each subscript position
until either a subscript value is not found, or the final
data value is located.
The VID pointing to the final data value is referred to as
the VID associated with the original variable. If this
final VID cannot be obtained, i.e. an intermediate or
final Value Table entry is not present, the value of the
variable is undefined and any attempt to obtain this
variable's value is erroneous.
To assign a value to a variable, the VID associated with
the variable is determined. If the VID exists, the data
value of the associated Value Table entry is updated with
the supplied value and the assign operation is completed.
Otherwise, some VIDs and Value Table entries must be
created.
If an intermediate Value Table entry exists, but an
appropriate subscript pair is missing, the pair is created
with the corresponding subscript value and a new (unique)
VID. Subsequent intermediate Value Table entries are then
created containing the VID, a reference count of one, the
undefined symbol as a value and a single subscript pair.
The subscript pair is created as described above. The
final Value Table entry is created containing the final
VID, a reference count of one, and the supplied new
variable value.
Certain MUMPS constructs will also require the use of a
Process Stack. This is a simple push-down stack, or
last-in-first-out (LIFO) list, used to save and restore
items which control the execution flow or variable
environment. Five types of items, or frames, will be used;
DO frames, exfunc frames, exvar frames, NEW frames, and
parameter frames:
a. DO frames contain only the execution location of the
doargument.
b. Exfunc and exvar frames contain a saved value of $T and
the execution location.
c. NEW frames contain a NEW argument (newarg) and a set of
Name Table entries.
d. Parameter frames contain a formallist and a set of Name
Table entries corresponding to call-by-reference
parameters.
Name Table Value Table
___________ _______________
| name | | VID |RfC|
| VID | | value |
|=========| | subs. pairs |
| ABC | |=============|
| 714 |--------------->| 714 | 1 |
|=========| | "HELLO" |
| XYZ | |=============|
| 86 |--------------->| 86 | 2 |
|=========| | undefined |
| BUF | |=============|
| 193 |--------------->| 193 | 1 |
|=========| | "ARRAY" |
| 1 |
+-----| 203 |
| | 2 |
| +--| 230 |
| | |=============|
| +->| 230 | 1 |
| | "JONES" |
| |=============|
+---->| 203 | 1 |
| undefined |
| "NUM" |
+--| 404 |
| |=============|
+->| 404 | 1 |
| "1234.5" |
|=============|
Variable Name VID Data Value $DATA
ABC 714 "HELLO" 1
XYZ 86 undefined 0
BUF 193 "ARRAY" 11
BUF(1) 203 undefined 10
BUF(2) 230 "JONES" 1
BUF(1,"NUM") 404 1234.5 1
Figure 1
Section 3.2.7 Intrinsic Special Variable Name svn
Intrinsic special variables are denoted by the prefix $
followed by one of a designated list of names.
Intrinsic special variable names differing only in the
use of corresponding upper and lower case letters are
equivalent. Any of the following defined intrinsic
special variables satisifies the definition of svn.
. . .
$Z[unspecified]
Z is the initial letter reserved for defining
non-standard intrinsic special variables. The
requirement that $Z be used permits the unused initial
letters to be reserved for future enhancement of the
standard without altering the execution of existing
programs which observe the rules of the standard.
Section 3.2.8 Intrinsic Functions function
Intrinsic functions are denoted by the prefix $ followed by
one of a designated list of names, followed by a
parathesized argument list. Intrinsic function names
differing only in the use of corresponding upper and lower
case letters are equivalent. Any of the following
specifications satisfies the definition of function.
. . .
$Z[unspecified] (unspecified)
is the name reserved for defining non-standard intrinsic
functions. This requirement permits the unused function
names to be reserved for future use.
. . .
$D[ATA] (glvn)
returns a non-negative integer which is a
characterization of the glvn. The value of the
integer is p+d, where:
d=1 if the glvn has a defined value, i.e. an associated VID
for the glvn exists and the Value Table entry pointed to by
the VID does not contain the "undefined" symbol;
d=0 otherwise;
p=10 if the variable has descendants; i.e. starting from
this glvn's Value Table entry there exists at least one
descendant path of linked Value Table entries which
contains an entry that does not include the "undefined"
symbol.
p=0 otherwise.
Section 3.2.10 (New Section)
3.2.10 Extrinsic Special Variable
exvar ::= $$ labelref
Extrinsic special variables are denoted by the prefix $$
followed by a labelref. Extrinsic special variables invoke
a MUMPS subroutine to return a value. When an extrinsic
special variable is executed, the current value of $T and
the current execution location are saved in an exvar frame
on the Process Stack.
Execution continues at the first command of the line
specified by the labelref.
Upon return from the subroutine the value of $T has been
restored, and the value of the argument of the QUIT command
that terminated the subroutine is returned as the value of
the exvar. An extrinsic special variable whose labelref is
x is identical to the extrinsic function:
$$x()
Section 3.2.11 (New Section)
3.2.11 Extrinsic Function
exfunc ::= $$ labelref actuallist
Extrinsic functions are denoted by the prefix $$ followed
by a labelref followed by an actuallist of parameters.
Extrinsic functions invoke a MUMPS subroutine to return a
value. When an extrinsic function is executed, the current
value of $T and the current execution location are saved in
an exfunc frame on the Process Stack. The actuallist
parameters are passed to the subroutine as described in
Section 3.5.9.
Execution continues at the first command of the line
specified by the labelref. This line must contain a
formallist in which the number of names is greater than or
equal to the number of names in the actuallist.
Upon return from the subroutine the value of $T has been
restored, and the value of the argument of the QUIT command
that terminated the subroutine is returned as the value of
the exfunc.
Section 3.4 Routines
change second sentence of second paragraph to:
Each line ends with eol, starts with ls optionally
preceded by a label and formallist of parameters,....
change definition of line to:
line ::= [ label [ formallist ]] ls ...
add definition of formallist :
formallist ::= ( [ L name ] )
add at end of section:
Each name in a given formallist must be unique.
Section 3.4.1 (New Section)
3.4.1 Routine Execution
Routine execution proceeds sequentially from line to line
starting with the line specified by the invoking label or
the first line of the routine if no label is given. Within
a line execution begins at the leftmost command and
proceeds sequentially from command to command.
It is an error to begin execution of any line that contains
a formallist unless that line has been reached as a result
of an exvar, exfunc, or a DO command doargument that
contains an actuallist.
Section 3.5.7 Line References
add at end of section:
When the DO command includes parameters to be passed to the
specified routines, the +intexpr form of lineref is not
permitted and the specified line must contain a formallist
after the defining label. The line specification labelref
is used instead:
labelref ::= dlabel [^| routineref ]
^| routineref
Section 3.5.9 (New Section)
3.5.9 Parameter Passing
Parameter passing is a method of passing information in a
controlled manner to and from a subroutine as the result of
an exfunc, an exvar, or a DO command command with an
actuallist.
actuallist ::= ([ L actual ])
actual ::= . actualname
expr
actualname ::= name
@ expratom V actualname
When parameter passing occurs, the line designated by the
labelref must contain a formallist in which the number of
names is greater than or equal to the number of actuals in
the actuallist. The correspondence between actual and
formallist name is defined such that the first actual in
the actuallist corresponds to the first name in the
formallist, the second actual corresponds to the second
formallist name etc. Similarly, the correspondence between
the parameter list entries, as defined below, and the
actual or formallist names is also by position in left to
right order. If the syntax of the actual is .actualname,
then it is said that the actual is of the call-by-reference
format; otherwise it is said that the actual is of the
call-by-value format.
When parameter passing occurs, the following steps are
executed:
a. Process the actuals in left-to-right order to
obtain a list of VIDs called the parameter list.
The parameter list contains one item per actual.
The parameter list is created according to the
following rules:
1. If the actual is call-by-value, evaluate the
expr and create a Value Table entry with a new
VID, a reference count of one, and a value
equal to the result of the evaluation. The
newly created VID is the parameter list item.
2. If the actual is call-by-reference, search the
Name Table for an entry containing the
actuallist name. If an entry is found, the
parameter list item is the VID in this Name
Table entry. If the actuallist name is not
found, create a Name Table entry containing
the name and a new VID. Also create a Value
Table entry containing this VID, a reference
count of one and the "undefined" symbol.
This VID is the parameter list item. In
either case, increase by one the reference
count of the Value Table entry pointed to by
the parameter list item.
b. Create a parameter frame on the Process Stack
containing the formallist.
c. For each name in the formallist, search the Name
Table for an entry containing the name and if the
entry exists, place the Name Table entry in the
parameter frame and delete it from the Name Table.
This step performs an implicit NEW on the
formallist names.
d. For each item in the parameter list, create a Name
Table entry containing the corresponding formallist
name and the parameter list item (VID). This step
"binds" the formallist names to their respective
actuals.
Execution then continues at the first command following
the ls of the line specified by the labelref. Execution
of the subroutine continues until an eor or a QUIT is
executed that is not within the scope of a subsequently
executed doargument, xargument, exfunc, exvar, or FOR.
In the case of an exfunc or exvar, the subroutine must be
terminated by a QUIT with an argument.
At the time of the QUIT, the formallist names are unbound
and the original variable environment is restored. See
Section 3.6.13 for a discussion of the semantics of the
QUIT operation.
Section 3.6.3 DO Command
D[O] postcond L doargument
entryref postcond
doargument::= labelref actuallist postcond
@ expratom V L doargument
DO is a generalized subroutine call.
If the actuallist is present in an executed doargument,
parameter passing occurs and the line designated by the
labelref must contain a formallist in which the number of
names is greater than or equal to the number of actuals
in the actuallist.
Each doargument is executed one at a time in
left-to-right order, with the following steps.
a. If a postcond is present and false, execution of
the doargument is complete. If postcond is absent,
or present and true, proceed to step b.
b. If the actuallist is present, execute the sequence
of steps described in Section 3.5.9 Parameter
Passing.
c. A DO-frame containing the current execution
location is placed on the Process Stack.
d. Continue execution at the first command following
the ls of the line specified by the entryref or
labelref. Execution of the subroutine continues
until an eor or a QUIT is executed that is not
within the scope of a subsequently executed FOR,
doargument, xargument, exfunc, or exvar. The scope
of this doargument is said to extend to the
execution of that QUIT or eor. See Section 3.6.13
(QUIT) for a description of the actions of the
termination operation. Execution then returns to
the first character position following the
doargument.
Section 3.6.10 Kill Command
K[ILL] postcond
L killargument
glvn
killargument ::= L lname
@ expratom V L killargument
lname ::= name
@ expratom V name
The three argument forms of KILL are given the following
names:
a. glvn: Selective Kill
b. (L name): Exclusive Kill
c. Empty argument list: Kill All
First, define the procedure K(N) where N is a glvn, as:
1. Find the VID associated with N. If no such VID exists,
the procedure terminates.
2. Apply subprocedure K1 to this VID.
3. If the value returned by K1 is less than two, delete
the Name Table entry.
The subprocedure K1(V), where V is a VID, is defined as:
1. Locate the Value Table entry pointed to by V.
2. Apply the subprocedure K1 to each of the VID's in the
subscript pairs in this Value Table entry. For each
call to K1 that returns a value less than 2, delete the
subscript pair.
3. If the reference count in this Value Table entry is
less than 2 and there are no subscript pairs present,
delete the Value Table entry. Otherwise, set the Value
of the entry to the "undefined" symbol.
4. Return as the value of the subprocedure the reference
count of this entry or zero if the entry has been
deleted.
Note that as a result of procedure K, $D(N)=0 i.e. the value
of N is undefined, and N has no defined descendants.
The actions of the three forms of KILL are then defined as:
a. Selective Kill - apply K to the specified glvn.
b. Exclusive Kill - apply K to all names in the Name Table
except those in the argument list. Note that the names
in the argument list of an exclusive kill may not be
subscripted.
c. Kill All - apply K to all names in the Name Table.
If a variable M is not killed but N, a descendant of M, is
killed, the killing of N affects the value of $D(M) as
follows: if N is not the only descendant of M, $D(M) is
unchanged; if M has a defined value $D(M) changes from 11 to
1; if M does not have a defined value $D(M) changes from 10
to 0.
Section 3.6.11 LOCK Last line
change to:
(See Section 3.2.2.3 for a definition of descendant.)
Section 3.6.11.5 (New Section)
3.6.11.5 New Command
N[EW] postcond [ ]
L newarg
lname
newarg ::= (L lname)
@ expratom V L newarg
NEW provides a means of performing variable scoping.
The three argument forms of NEW are given the following
names:
a. lname: Selective New
b. (L lname): Exclusive New
c. Empty argument list: New All.
Each argument of the NEW command pushes a frame containing
the NEW argument and a set of Name Table entries onto the
Process Stack.
The actions of the three forms of NEW are then defined as:
a. Selective New -the stacked frame contains the Name
Table entry for lname.
b. Exclusive New - the frame contains the set of Name
Table entries for all names except the names in the
argument.
c. New All - all entries in the Name Table are placed
in the frame.
In all three cases, the Name Table entries placed in the
frame are subsequently deleted from the Name Table. This
deletion has the effect of making the variable unknown in the
current process context.
Section 3.6.13 QUIT
Q[UIT] postcond SP
SP expr
QUIT terminates execution of a doargument, xargument,
exfunc, exvar, or FOR.
The end-of-routine mark eor is equivalent to an
unconditional QUIT. If the last command of the routine is
executed in such a manner as not to transfer control, then
the effect of executing off the end of the routine is to
execute the QUIT which is implied by the eor.
The effect of executing QUIT in the scope of FOR is fully
discussed in 3.6.5. Note the eor never occurs in the
scope of FOR.
If an executed QUIT is not in the scope of FOR, then it is
in the scope of some doargument, xargument, exfunc, or
exvar if not explicitly then implicitly, because the
initial activation of a process, including that due to
execution of a jobargument, may be thought of as arising
from execution of a DO naming the first executed routine
of that process.
The effect of executing a QUIT in the scope of a
doargument, xargument, exfunc, or exvar is to restore a
previous variable environment (if necessary) and return
control to the most recently executed (invoking)
doargument, xargument, exfunc, or exvar.
If the expr is present in the QUIT, this return must be to
an exfunc or exvar. Similarily, if the expr is not
present, the return must be to a doargument or xargument.
Any other case is erroneous.
The following steps are executed when a QUIT is
encountered:
a. If an expr is present, evaluate it. This
value becomes the value of the invoking exfunc or
exvar.
b. Remove the frame on the top of the Process Stack.
c. If that frame is from a NEW examine the saved
argument of the NEW and take one of the following
actions dependent on the argument types:
1. Selective NEW - perform an implicit KILL on the
argument lname.
2. Exclusive NEW - perform an implicit KILL on all
names in the Name Table except those in the
argument.
3. New All - perform an implicit Kill All.
Finally retrieve all Name Table entries from the
frame and restore them to the Name Table. This
action restores a previous variable environment.
Processing of this frame is complete, continue at
Step b.
d. If the frame is a parameter frame, process each name
in the formallist with the following steps:
1. Search the Name Table for an entry containing
the name. If no such entry is found,
processing of this name is complete.
Otherwise, proceed to step 2.
2. Locate the entry in the Value Table pointed to
by the VID in this Name Table entry and reduce
its reference count by one. If the reference
count is now zero, delete the Value Table entry.
3. Delete the Name Table entry for this name.
Finally, retrieve all Name Table entries from the
frame and restore them to the Name Table.
Processing of this frame is complete, continue at
Step b.
e. If the frame is from an exfunc or exvar set the
value of $T to the value saved in the frame.
f. Return control to the location specified in the
frame.
Section 3.6.14 READ Paragraph 2
replace the first sentence with:
The top two argument forms cause output operations to
the current device, the next two cause input from the
current device to the named local variable (see Section
3.2.2.3 for a description of the value assignment
operation).
Section 3.6.15 SET
replace c.1 with:
1. If the left-hand side of the set is one or more
glvns, the value of expr is given to each glvn in
left-to-right order (see Section 3.2.2.3 for a
description of the value assignment operation).
------------------------------
Date: Thursday, 2 May 1985 10:38:06-PDT
From: nimbus.DEC!gallagher (Donna M. Gallagher MRO3-2/H7 DTN: 231-2372)
Subject: Routine Structure - Jack Bowie - 5/2/85
To: seismo.uucp!plus5!std-mumps, gallagher%nimbus.DEC
Block Structure Proposal
Table of Contents - Part I
. . .
3.4.1 Routine Structure
3.4.2 Routine Execution
. . .
Section 3.2.10 Extrinsic Special Variable
add at end of second paragraph:
. . . This line must have a level of one. Execution of an
exvar to a line whose level is not one is erroneous.
Section 3.2.11 Extrinsic Function
add at end of second paragraph:
. . . This line must have a level of one. Execution of an
exfunc to a line whose level is not one is erroneous.
Section 3.4 Routines
add new heading at top:
3.4.1 Routine Structure
change second sentence of second paragraph to:
Each line starts with an optional label and formallist which is
followed by one or more ls. The number of ls is called the
level of the line. Following the last ls are zero or more
commands and a terminating eol.
change definition of line to:
line::= [label [formallist ]] ls [ . ls ... ]...
add at end of section:
A formallist may only be present on a line whose level is one,
i.e. contains only one ls.
Section 3.4.2 Routine Execution (New Section number)
MUMPS routines are executed in a sequence of blocks. Each
block is invoked by the instance of an argumentless DO command,
a doargument, an exfunc, or an exvar and consists of the
execution of a set of lines, all having the same level, between
the line reference implied by the DO, exfunc, or exvar and an
implicit or explicit QUIT command. If no label is specified in
the doargument, exfunc, or exvar, the first line of the routine
is used.
Routine execution proceeds sequentially from each line to the
next line in the routine. Within a line, execution begins at
the leftmost command and proceeds sequentially from command to
command. A current execution level is defined upon entry to
any block. Lines having levels higher than the current level
are ignored, i.e., not executed. When a line with a lower
level, or the eor is encountered, an implicit QUIT command is
executed, terminating this execution block (see Section 3.6.13
for a description of the actions of QUIT). The initial
execution level for a process is one.
It is an error to begin execution of any line that contains a
formallist unless that line has been reached as the result of
an exvar, an exfunc, or a DO command doargument that contains
an actuallist.
Section 3.6.3 DO Command
D[O] postcond SP
L doargument
entryref postcond
doargument::= labelref actuallist postcond
@ expratom V L doargument
DO without arguments initiates execution of an inner block of
lines. If postcond is present and false, execution of the
command is complete. If postcond is absent, or present and
true, the DO places a DO frame containing the current execution
location on the Process Stack, increases the execution level by
one, and continues execution at the next line in the routine.
(See Section 3.4.2 for an explanation of routine execution).
When execution of this block is completed, i.e. upon
encountering an implicit or explicit QUIT not within the scope
of a subsequently executed doargument, xargument, exfunc,
exvar, or FOR, the DO frame is removed from the stack, the
original execution level is restored, and execution resumes at
the command (if any) following the argumentless DO.
DO with arguments is a generalized call to the subroutine
specified by the entryref, or labelref, in each doargument.
The line specified by the entryref or labelref must have a
level of one. Execution of a doargument to a line whose level
is not one is erroneous.
. . .
Section 3.6.6 GOTO
add at end of second paragraph:
... If such a gotoargument is found, execution continues at the
left of the line it specifies provided the line satisfies both
of the following conditions.
a. The line has the same execution level as the line
containing the GOTO.
b. The line is in the same nested block as the invoking line,
i.e. there are no lines of lower execution level between
the line specified by the gotoargument and the line
containing the GOTO.
------------------------------
End of std-mumps Digest
******************************