In MUMPS syntax, spaces are significant: there are contexts in which a pair of spaces is interpreted differently from a single space. As a result, and unlike most programming languages, spaces cannot be inserted freely for readability, except within comments. Some vendors offer non-standard language enhancements that let you break this rule.

A typical M procedure consists of several "blocks", each block separated by a label in the first column. Calling into the procedure with no label results in the procedure being run from the first line, whereas calling with a label skips to that point. By convention, interactive commands can be placed at the top of the procedure and then a label defines the actual start of the code itself. This allows the procedure to be used both interactively and as a function to be called from other code. It is not possible to define command line macros in M, but it is possible to type any line of M code and execute it immediately, including subroutines calls.

One main difference between M and most other languages is that M has only a single data type, the string, which it invisibly converts into common data types such as numbers or dates. Automated conversion of this sort is common to many scripting programming languages. As you might expect, M includes a complete and powerful set of string manipulation commands, grouped into libraries.

The key to the M language is that all variables are automatically multi-dimensional. For instance, this command:

SET A="abc"

creates the variable A and sets its value to the string. The same variable can then be used to hold additional information:

SET A(1,2)="def"

Will place the string def into "slot" (1,2). Slots can also be designated with strings:

SET A("first_name")="Bob"

SET A("last_name")="Dobbs"

making the variables useful data stores on their own. Note that this example also demonstrates another feature of M, that assignments into variables do not erase other information already there. This makes it easy to create complex variables (similar to objects in other languages), using several assignments.

M variables work in a similar fashion as with other programming languages, in that when the program exits, the value will be lost. M comes into its own with its concept of globals, variables which are automatically and invisibly stored to the datastore. Globals appear as normal variables with the caret character in front of the name. Modifying the earlier example thus:

SET ^A("first_name")="Bob"

SET ^A("last_name")="Dobbs"

will result in a new record being created and inserted in the datastore.

One difference between M and the traditional SQL model of a database is the "level" of the commands in the language. M is a general purpose language with a datastore, whereas SQL is a language dedicated to database functions. This might sound like a minor distinction, but it is rather important to understand it. For instance, SQL includes a search function:

SELECT * FROM user WHERE first_name like 'Bob%'

returns a list of matching records. M has no equivalent "high level" command like SELECT, instead the programmer must construct a small routine in order to find the matching records returned from its lower-level functions. The language includes full support for Transaction Processing and most implementations include transaction logs (in the form of journal files) and some kind of user based security.

For all of these reasons one of the most common M programs is a database management system, providing all of the classic ACID properties on top of a generic M implementation. FileMan is one such example.

Most M implementations include fairly complete support for multi-tasking, multi-user, multi-machine programming. To demonstrate the ease of multi-machine support, consider:

SET ^|"DENVER"|A("first_name")="Bob"

SET ^|"DENVER"|A("last_name")="Dobbs"

which sets up A as before, but this time on the remote machine called "DENVER". M programs are thus trivial to distribute over many machines. This support also made it easy to expose the same sorts of distribution in the SQL (and other) layers with ease, and it's not uncommon for M systems to be a better distributed SQL solution than a "real" SQL system.

Another use of M in more recent times has been to create object databases.