|
STANDARD 11756
First edition
1992-1 2-1 5
e
Informgtion technology - Programming languages -
MUMPS
Technologies de l’information - Langages de programmation - MUMPS
O
Reference number
ISO/IEC 11756:1992 (E)
---------------------- Page: 1 ----------------------
ISO/IEC 11756:1992 (E)
I Table of Contents
Part 1: MUMPS Language Specification
1 Static Syntax Metalanguage . 2
2 Static Syntax and Semantics . 3
2.1 Basic Alphabet . 3
2.2 Expression Atom expratom . '. . 3
4
2.2.1 Name name .
2.2.2Variables . 4
2.2.2.1 Local Variable Name . 4
2.2.2.2 Global Variable Name . 5
2.2.2.3 Variable Handling . 6
2.2.2.4 Variable Contexts . 9
9
2.2.3 Numeric Literal numlit .
2.2.3.1 Numeric Data Values . 10
2.2.3.2 Meaning of numlit . 1 O
2.2.4 Numeric Interpretation of Data . 11
2.2.4.1 Integer Interpretation . 12
2.2.4.2 Truth-value Interpretation . 12
2.2.5 String Literal 3 . 12
2.2.6 Intrinsic Special Variable Name . 13
2.2.7 Intrinsic Functions function . 15
2.2.7.1 $ASCII . 15
2.2.7.2$CHAR . 16
2.2.7.3$DATA . 16
2.2.7.4$EXTRACT . 17
2.2.7.5$FIND . 17
2.2.7.6 $FNUMBER . 18
2.2.7.7$GET . 19
2.2.7.8 $JUSTIFY . 19
2.2.7.9 $LENGTH . 20
2.2.7.10$NEXT . 20
2.2.7.11 $ORDER . 21
2.2.7.12 $PIECE . 21
2.2.7.13 $QUERY. . 22
2.2.7.14 $RANDOM . 24
O ISOAEC 1992
All rights reserved . No part of this püblication may be reproduced or utilized in any form or by
any means. electronic or mechanical. including photocopying and microfilm. without
permission in writing from the publisher .
ISOAEC Copyright Office Case postale 56 CH-1211 Genève 20 Switzerland
Printed in Switzerland
ii
---------------------- Page: 2 ----------------------
ISO/IEC 11756:1992 (E)
2.2.7.15$SELECT . . 24
2.2.7.16$TEXT . 24
2.2.7.18 $VIEW . 25
2.2.7.19$Z . 25
2.2.8 Unary Operator unaryop . 25
2.2.9 Extrinsic Special Variable . 25
2.2.10 Extrinsic Function . 26
2.3 Expressions . 26
27
2.3.1 Arithmetic Binary Operators .
2.3.2 Relational Operators . 27
2.3.2.1 Numeric Relations . 28
2.3.2.2 String Relations . 28
2.3.3 Pattern match . 28
2.3.4 Logical Operators .
29
2.3.5 Concatenation Operator . 30
2.4 Routines . 31
2.4.1 Routine Structure . 31
31
2.4.2 Routine Execution .
32
2.5 General command Rules .
2.5.1 Post Conditionals . 33
2.5.2 Spaces in Commands . 34
2.5.3Comments . 34
2.5.4 format in READ and WRITE . 34
2.5.5 Side Effects on $X and $Y . 34
2.5.6Timeout . 35
2.5.7 Line References . 35
2.5.8 Command Argument Indirection . 36
2.5.9 Parameter Passing . 37
2.6 Command Definitions . 37
2.6.1 BREAK . 39
2.6.2CLOSE . 39
2.6.3 DO . 39
2.6.4 ELSE . 40
2.6.5FOR . 41
41
2.6.6GOTO .
2.6.7HALT . 43
43
2.6.8 HANG .
2.6.9IF . 43
44
2.6.10JOB .
44
2.6.11 KILL .
45
2.6.12LOCK .
2.6.13NEW . 46
2.6.14 OPEN . 48
2.6.15QUlT . 49
2.6.16 READ . 49
51
2.6.17SET .
52
2.6.18 USE .
2.6.19VlEW . 53
54
2.6.20WRlTE .
2.6.21 XECUTE . 54
55
...
III
---------------------- Page: 3 ----------------------
ISO/IEC 11756:1992 (E)
Part 2 MUMPS Portability requirements
Introduction .
61
1 Expression Elements .
62
1.1 Names .
62
1.2 LocalVariables .
62
1.3 Global Variables .
62
1.4 DataTypes .
63
1.5 Number Range .
63
1.6 Integers .
64
1.7 Character Strings .
64
1.8 Special Variables .
64
2 Expressions .
64
2.1 Nesting of Expressions .
64
2.2 Results .
64
3 Routines and Command Lines .
64
e
3.1 Command Lines .
64
3.2 Number of Command Lines .
65
3.3 Number of Commands .
65
3.4 Labels .
65
3.5 Number of Labels .
65
3.6 Number of Routines .
65
4 Indirection .
65
5 Storage Space Restrictions .
65
6 Nesting .
66
7 Other Portability Requirements .
66
Appendix A ASCII Character Set (ANSI X3.4-1986). .
67
Appendix B Metalanguage Elements .
71
O
Index .
81
iv
---------------------- Page: 4 ----------------------
ISO/IEC 11756:1992 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide
standardization. National bodies that are members of IS0 or IEC participate in
the development of International Standards through technical committees
established by the respective organization to deal with particular fields of
technical activity. IS0 and IEC technical committees collaborate in fields of
mutual interest. Other international organizations, governmental and non-
governmental, in liaison with IS0 and IEC, also take part in the work.
In the field of information technology, IS0 and IEC have established a joint
technical committee, ISO/IEC JTC 1. Draft International Standards adopted by the
joint technical committee are circulated to national bodies for voting. Publication
as an International Standard requires approval by at least 75 % of the national
bodies casting a vote.
International Standard ISO/IEC 11756 was prepared by American National
Standards Institute (ANSI) (as ANSI/MDC X1l.l-1990) and was adopted, under a
special "fast-track procedure", by Joint Technical Committee ISO/IEC JTC 1,
lnformation technology, in parallel with its approval by national bodies of IS0
and IEC.
Appendices A and B of this International Standard are for information only.
Terminology and conventions
The text of American National Standard Institute ANSI/MDC Xll.I-l990 has been
approved for pubtication, without deviation, as an International Standard. Some
terminology and certain conventions are not in accordance with the ISO/IEC
Directives Part 3: "Drafting and presentation of International Standards"; attention
is especially drawn to the following:
Wherever the word "standard" appears, referring to this International Standard, it
should be read as "International Standard".
Cross reference
American National Corresponding International Standard
Standard
ANSI X3.4-1986 ISO/IEC 646: 1991, Information technology - IS0 7-bit
coded character set for information interchange.
V
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO/IEC 11756:1992 (E)
Information technology - Programming languages -
MUMPS
Part 1: MUMPS Language Specification
Introduction
Part 1 consists of two sections that describe the MUMPS language. Section 1 describes the
metalanguage used in the remainder of Part 1 for the static syntax. Section 2 describes the static
syntax and overall semantics of the language. The distinction between 'static" and "dynamic" syntax
is as follows. The static syntax describes the sequence of characters in a routine as it appears on
a tape in routine interchange or on a listing. The dynamic syntax describes the sequence of
characters that would be encountered by an interpreter during execution of the routine. (There is no
requirement that MUMPS actually be interpreted). The dynamic syntax takes into account transfers
of control and values produced by indirection.
1
---------------------- Page: 6 ----------------------
ISO/IEC 11756:1992 (E)
1 Static Syntax Metalanguage
The primitives of the metalanguage are the ASCII characters. The metalanguage operators are defined as
follows:
Operator Meaning
..- definition
[I option
grouping
II
... optional indefinite repetition
- L list
!! value
- SP space
The following visible representations of ASCII characters required in the defined syntactic objects are used:
_I SP (space), CR (carriage-return), E (line-feed), and E (form-feed).
In general, defined syntactic objects will have designators which are underlined names spelled with lower case
letters, e.g., name, expr, etc. Concatenation of syntactic objects is expressed by horizontal juxtaposition,
choice is expressed by vertical juxtaposition. The ::= symbol denotes a syntactic definition. An optional
element is enclosed in square brackets [ 1, and three dots . denote that the previous element is optionally
repeated any number of times. The definition of name, for example, is written:
name ::= 8 diqit j .
-
laïpha I I alpha ,
The vertical bars are used to group elements or to make a choice of elements more readable.
Special care is taken to avoid any danger of confusing the square brackets in the metalanguage with the ASCII
graphics ] and [. Normally, the square brackets will stand for the metalanguage symbols.
The unary metalanguage operator C denotes a list of one or more occurrences of the syntactic object
immediately to its right, with one comma between each pair of occurrences. Thus,
-- L name is equivalent to name [ , name ] . .
The binary metalanguage operator y places the constraint on the syntactic object to its left that it must have
a value which satisfies the syntax of the syntactic object to its right. For example, one might define the syntax
of a hypothetical EXAMPLE command with its argument list by
examplecommand : : = EXAMPLE sp 4 examplearqument
where
expr
exampiearqument : : = I
I
I @ expratom 1 exampiearqument I
This example states: after evaluation of indirection, the command argument list consists of any number of
exprs separated by commas. In the static syntax (i.e., prior to evaluation of indirection), occurrences of @
expratom may stand in place of nonoverlapping sublists of command arguments. Usually, the text
accompanying a syntax description incorporating indirection will describe the syntax after all occurrences of
indirection have been evaluated.
---------------------- Page: 7 ----------------------
ISO/IEC 11756:1992 (E)
2 Static Syntax and Semantics
2.1 Basic Alphabet
The routine, which is the object whose static syntax is being described in Section 2, is a string made up of the
following 98 ASCII symbols.
The 95 printable characters, including the space character represented as Sp, and also,
the carriage-return character represented as CR,
the line-feed character represented as E,
the form-feed character represented as E.
See 2.4 for the definition of routine.
The syntactic types graphic, alpha, dig-, and nonquote are defined here informally in order to save space.
qraphic ::= any of the class of 95 ASCII printable characters, including
SP .
-
nonquote ::= any of the characters in graphic except the quote character.
alpha ::= any of the class of 52 upper and lower case letters: A-2,
a-z.
diqit ::= any of the class of 10 digits: 0-9.
2.2 Expression Atom expratom
The expression, m, is the syntactic element which denotes the execution of a value-producing calculation;
it is defined in 2.3. The expression atom, expratom, is the basic value-denoting object of which expressions
are built; it is defined here.
I& I
expratom : := I qvn
expritem
See 2.2.2.1 for the definition of h. See 2.2.2.2 for the definition of gvn.
svn
-
function
exfunc
exvar
expritem ::= numl i t
strlit
(23x1
unaryop expratom
See 2.2.6 for the definition of çvn. See 2.2.7 for the definition of functi<
7. See 2.2.10 for the definition of
exfunc. See 2.2.9 for the definition of m. See 2.2.3 for the definition c numlit. See 2.2.5 for the definition
of çtrlit. See 2.3 for the definition of x.
1'1 (Note: apostrophe
: :=
unaryop
(Note: hyphen)
3
---------------------- Page: 8 ----------------------
ISO/IEC 11756~992 (E)
2.2.1 Name name
...
See 2.1 for the definition of alpha and a.
2.2.2 Variables
The MUMPS standard uses the terms local variables and global variables somewhat differently from their
connotation in certain other computer languages. This section provides a definition of these terms as used
in the MUMPS environment.
A MUMPS routine, or set of routines, runs in the context of an operating system process. During its execution,
the routine will create and modify variables that are restricted to its process. It can also access (or create)
variables that can be shared with other processes. These shared variables will normally be stored on
secondary peripheral devices such as disks. At the termination of the process, the process-specific variables
cease to exist. The variables created for long term (shared) use remain on auxiliary storage devices where
they may be accessed by subsequent processes.
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’ lifetime. MUMPS does include certain constructs, the NEW command
and parameter passing, which limit the availabiliîy of certain variables to specific routines or parts of routines.
See 2.2.2.3 for a further discussion of variables and variable environments.
A global variable is one that is created by a MUMPS process, but is permanent and shared. As soon as it
has been created, it is accessible to other MUMPS processes on the system. Global variables do not
disappear when a process terminates. Like local variables, global variables are available to all routines
executed within a process.
2.2.2.1 Local Variable Name
lvn
-
See 2.2 for the definition of expratom. See section I for the definition of x.
rlvn
-
See 2.2.1 for the definition of name. See 2.3 for the definition of E. See section 1 for the definition of !=.
lnamind ::= rexpratom V lvn
See section 1 for the definition of y.
I
rexpratom ::= rgvn
i zitem
I
4
---------------------- Page: 9 ----------------------
ISO/IEC 1'9756:1992 (E)
See 2.2.2.2 for the definition of m. See 2.2 for the definition of expritem.
A local variable name is either unsubscripted or subscripted; if it is subscripted, any number of subscripts
separated by commas is permitted. An unsubscripted occurrence of may carry a different value from any
subscripted occurrence of &.
When lnamind is present it is always a component of an m. If the value of the is a subscripted form of
- Ivn, then some of its subscripts may have originated in the Inamind. In this case, the subscripts contributed
by the lnamind appear as the first subscripts in the value of the resulting separated by a comma from the
(non-empty) list of subscripts appearing in the rest of the G.
2.2.2.2 Global Variable Name ~vn
See section 1 for the definition of 1.
See 2.2 for the definition of expratom.
I
rgvn . name [ (
L expr ) ]
@ qnamind @ ( L expr )
See 2.2.1 for the definition of name. See section 1 for the definition of C.
See 2.3 for the definition of m.
gnamind ::= I rexpratom V qvn I'
See section 1 for the definition of y.
The prefix uniquely denotes a global variable name. A global variable name is either unsubscripted or
subscripted; if it is subscripted, any number of subscripts separated by commas is permitted. An abbreviated
form of subscripted gvn is permitted, called the naked reference, in which the prefix is present but the name
and an initial (possibly empty) sequence of subscripts is absent but implied by the value of the naked indimfor.
An unsubscripted occurrence of gvn may carry a different value from any subscripted Occurrence of qvn.
is a subscripted form
When gnamind is present it is always a component of an w. If the value of the
of gvn, then some of its subscripts may have originated in the gnamind. In this case, the subscripts
contributed by the gnamind appear as the first subscripts in the value of the resulting rg~, separated by a
comma from the (non-empty) list of subscripts appearing in the rest of the m.
Every executed occurrence of CJVJ affects the naked indicator as follows. If, for any positive integer m, the qvn
has the nonnaked form
N(v1 I v2 9 e. , v, )
then the m-tuple N, v, , v2 , . , v,,,.~ , is placed into the naked indicator when the QVJ reference is made. A
subsequent naked reference of the form
(i positive)
A(sl I s2 I . , s,)
results in a global reference of the form
N(v, 9 v2 I e** I V,.l 9 s, 9 s, , .** , s,)
5
---------------------- Page: 10 ----------------------
ISO/IEC 11756:1992 (E)
U
after which the m+i-l-tuple N, vl , v, , . , si., is placed into the naked indicator. Prior to the first executed
occurrence of a nonnaked form of gvn, the value of the naked indicator is undefined. It is erroneous for the
first executed occurrence of gvn to be a naked reference. A nonnaked reference without subscripts leaves
the naked indicator undefined.
The effect on the naked indicator described above occurs regardless of the context in which E is found; in
particular, an assignment of a value to a global variable with the command SET qvn = does not affect
the value of the naked indicator until after the right-side has been evaluated. The effect on the naked
indicator of any= within the right-side ~XJIJ will precede the effect on the naked indicator of the left-side gvn.
For convenience, & is defined so as to be satisfied by the syntax of either gv~ or m.
See 2.2.2.1 for the definition of b.
2.2.2.3 Variable Handling
MUMPS has no explicit declaration or definition statements. Local and global variables, both non-subscripted
and subscripted, are automatically created as data is stored into them, and their data contents can be referred
to once information has been stored. Since the language has only one data type - string - there is no need
for type declarations or explicit data type conversions. Array structures can be multidimensional with data
simultaneously stored at all levels including the variable name level. Subscripts can be positive, negative,
and/or noninteger numbers as well as nonnumeric strings (other than empty strings).
In general, the operation of the local variable symbol table can be viewed as follows. Prior to the initial setting
of information into a variable, the data value of that variable is said to be undefined. Data is stored into a
variable with commands such as SET, READ, or FOR. Subsequent references to that variable return the data
value that was most recently stored. When a variable is killed, as with the KILL command, that variable and
all of its array descendants (if any) are deleted, and their data values become undefined.
No explicit syntax is needed for a routine or subroutine to have access to the local variables of its caller.
Except when the NEW command or parameter passing is being used, a subroutine or called routine (the
callee) has the same set of variable values as its caller and, upon completion of the called routine or
subroutine, the caller resumes execution with the same set of variable values as the callee had at its
corn pl e ti on.
The NEW command provides scoping of local variables. It causes the current values of a specified set of
variables to be saved. The variables are then set to undefined data values. Upon returning to the caller of
the current routine or subroutine, the saved values, including any undefined states, are restored to those
variables. Parameter passing, including the DO command, extrinsic functions, and extrinsic variables, allows
parameters to be passed into a subroutine or routine without the callee being concerned with the variable
names used by the caller for the data being passed or returned.
of MUMPS local variables with their values can best be described by a conceptual
The formal association
model. This 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 structures: the NAME-
TABLE and the VALUE-TABLE. (in reality, at least two such table sets are required, one pair per executing
process for process-specific local variables and one pair 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
6
---------------------- Page: 11 ----------------------
ISO/IEC 11756:1992 (E)
passing or nested environments apply only to local variables, the discussion that follows will address only local
variable value association. It should be noted, however, that while the overall structures of the table sets are
the same, there are two major differences in the way the sets are used. First, the global variable tables are
shared. This means that any operations on the global tables, e.g., SET or KILL, by one process, affect the
tables for all processes. Second, since scoping issues of parameter passing and the NEW command are not
applicable to global variables, there is always a one-to-one relationship between entries in the global NAME-
TABLE (variable names) and entries in the global VALUE-TABLE (values).
The NAME-TABLE consists of a set of entries, each of which contains a name and a pointer. This pointer
represents a correspondence between that name and exactly one DATA-CELL from the VALUE-TABLE. The
VALUE-TABLE consists of a set of DATA-CELLS, each of which contains zero or more tuples of varying
degrees. The degree of a tuple is the number (possibly O) of elements or subscripts in the tuple list. Each
tuple present in the DATA-CELL has an associated data value.
The NAME-TABLE entries contain every non-subscripted variable or array name (name) known, or accessible,
by the MUMPS process in the current environment. The VALUE-TABLE DATA-CELLS contain the set of tuples
that represent all variables currently having data-values for the process. Every name (entry) in the NAME-
TABLE refers (points) to exactly one DATA-CELL, and every entry contains a unique name. Several NAME-
TABLE entries (names) can refer to the same DATA-CELL, however, and thus there is a many-to-one
relationship between (all) NAME-TABLE entries and DATA-CELLS. A name is said to be bound to its
corresponding DATA-CELL through the pointer in the NAME-TABLE entry. Thus the pointer is used to
represent the correspondence and the phrase change the pointer is the equivalent to saying change the
correspondence so that a me now corresponds to a possible different DATA-CELL (value). NAME-TABLE
entries are also placed in the PROCESS-STACK (see 2.2.2.4).
The value of an unsubscripted !VJ corresponds to the tuple of degree O found in the DATA-CELL that is bound
to the NAME-TABLE entry containing the name of the h. The value of a subscripted h (array node) of
degree n also corresponds to a tuple in the DATA-CELL that is bound to the NAME-TABLE entry containing
the name of the h. The specific tuple in that DATA-CELL is the tuple of degree n such that each subscript
of the has the same value as the corresponding element of the tuple. If the designated tuple doesn’t exist
in the DATA-CELL then the corresponding & is said to be undefined.
7
---------------------- Page: 12 ----------------------
ISO/IEC 11756:1992 (E)
In the following figure, the variables and array nodes have the designated data values.
VAR7 = "Hello"
VAR2 = 12.34
VAR3 = "abc"
VAR3("Smith","John",l234)=123
VAR3("Widget","red") = -56
Also, the variable DEF existed at one time but no longer has any data or array value, and the variable XYZ
has been bound through parameter passing to the same data and array information as the variable VAR2
NAME-TABLE VALUE-TABLE DATA-CELLS
()="abc"
( " Smith " , I' John " ,12 3 4 ) = 12 3
i
I
( "Widget", "red")=-56
DEF----------->
I
2
The initial state of a MUMPS process prior to execution of any MUMPS code consists of an empty NAME-
TABLE and VALUE-TABLE. When information is to be stored (set, given, or assigned) into a variable WnJ:
a. If the name of the !VJ does not already appear in an entry in the NAME-TABLE, an entry is added
to the NAME-TABLE which contains the name and a pointer to a new (empty) DATA-CELL. The
corresponding DATA-CELL is added to the VALUE-TABLE without any initial tuples.
b. Otherwise, the pointer in the NAME-TABLE entry which contained the name of the !VJ is
extracted. The operations in step c. and d. refer to tuples in that DATA-CELL referred to by this
pointer.
c. If the !VJ is unsubscripted, then the tuple of degree O in the DATA-CELL has its data value
replaced by the new data value. If that tuple did not already exist, it is created with the new data
value.
d. If the !VJ is subscripted, then the tuple of subscripts in the DATA-CELL (i.e., the tuple created by
dropping the name of the ivn; the degree of the tuple equals the number of subscripts) has its data
value replaced by the new data value. If that tuple did not already exist, it is created with the new
data value.
When information is to be retrieved, if the name of the !VJ is not found in the NAME-TABLE, or if its
corresponding DATA-CELL tuple does not exist, then the data value is said to be undefined. Otherwise, the
data value exists and is retrieved. A data value of the empty string (a string of zero length) is not the same
as an undefined data value.
8
---------------------
...