|
Page: Variables and Datatypes
Main article
| Home > Child Health > Variables and Datatypes |
The chief difference between MUMPS and other programming languages is that MUMPS does not require declaration of variables by datatype (or to declare them at all!). They are all, in effect, strings. Numbers may be represented as strings. Variable use in a numeric context (eg, addition, subtraction) invokes a well-defined conversion in case the string is not a canonical number, such as "123 Main Street".
MUMPS inherently includes a complete and powerful set of string manipulation commands.
MUMPS includes sparse array management rountines for "memory variables". Those arrays are process-connected and disappear with the termination of the process in which they were created. Disk resident (ie, database) sparse variables (called "global variables" in MUMPS terminology) incur very little space penalty when written to disk, and are automatically stored in hierarchical structures on disk. Most implementations are careful to use highly optimized disk routines to reduce the time/space cost of disk references.
In a MUMPS context, 'sparse arrays' are those with 'missing' elements; there is no requirement for sequential nodes to exist — A(1), A(99) and A(100) may be used without defining, allocating space for, or using any space for, nodes 2 through 98. Indeed, one can use fractional numbers ( A(1.2), A(3.3), etc) where the numbers have some meaning external to the program. The access function $ORDER ( A(1.2) ) returns the next defined key or subscript value, 3.3 in this example, so the program can readily manage the data. This implements an automatic sort feature, inherent in the standard language, with very little processing cost.
This feature is often used in global index functions where the sort key is used as a global subscript, eg, (^INDEX (lastname, firstname, SSNumber)=... ).
SET A="abc"
creates the variable A and sets its value to the string, abc. An array with the same name is distinct in the namespace --
SET A(1,2)="def"
Subscripts may be string valued as well as integer or numeric-valued (eg, A(1.2)).
SET A("first_name")="Bob"
SET A("last_name")="Dobbs"
which makes the variable names useful data stores independently of the variable contents.
MUMPS' memory resident (ie, local) variables work in a similar fashion as in other programming languages; when the program (or routine) exits, variable values are discarded.
[edit] Global variables - the database
MUMPS' concept of globals is particularly practical. Globals are variables which are automatically and transparently stored on disk and persist beyond program, routine, or process completion. Globals are used exactly like ordinary variables, but with the caret character prefixed to the variable name. Modifying the earlier example as follows
SET ^A("first_name")="Bob"
SET ^A("last_name")="Dobbs"
results in creation of a new disk record, which is immediately inserted within the file structure of the disk. It is persistent, just as a file persists in most operating systems. Globals are stored in highly structured data files by MUMPS, and accessed only as MUMPS globals. MUMPS has a long history of efficient, stable, theoretically-sound cached, journaled, and balanced B-tree key/value disk storage, including sophisticated transaction control for multiple file transaction 'commit' and 'roll-back' at the language/operating system level. Huge databases in the real world commonly grow randomly rather than in a preset sequence, and the MUMPS system handles each with carefully optimized internal algorithms invisible to the MUMPS programmer, thus saving considerable time and coding effort. Missing information, common in real world database situations, does not inherently cause trouble (eg, errors, exceptions, abends, ...).
For all of these reasons, one of the most common MUMPS applications is database management. MUMPS can easily provide the classic ACID properties on top of any standard MUMPS implementation. FileMan is an example. Intersystems' Cache' implmentation allows dual views of selected data structures—as MUMPS globals, or as SQL data—and has SQL built in (called M/SQL). The MUMPS view allows programmers rather more control of the data, as there is no requirement to fit the data into the assumed rows and columns of relational SQL.
|
Important notice:
The content is not intended to be a substitute for professional medical advice, diagnosis, or treatment. Always seek the advice of your physician or other
qualified health provider with any questions you may have regarding a medical condition.
|