☜	Parameter Passing Draft MDC Standard					☞

8.1.7 Parameter passing

Parameter passing is a method of passing information in a controlled manner to and from a subroutine or process as the result of an exfunc, or a Do command with an actuallist, or to a process as the result of a Job command with an actuallist.

When parameter passing occurs, the formalline 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, et cetera. 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 actual is .actualname, then it is said that the actual is of the call-by-reference format; if the syntax of actual is expr it is said that the actual is of the call-by-value format; otherwise it is said that the actual is of the omitted-parameter format.

When parameter passing occurs, the following steps are executed:

1. Process the actuals in left-to-right order to obtain a list of DATA-CELL pointers 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, then evaluate the expr and create a DATA-CELL with a zero tuple value equal to the result of the evaluation. An expr that returns a value of data type OREF is coerced into a value of data type MVAL in the actuallist of externrefs and Job commands (See 7.1.1.1.2 for the coercion rules), but not in any other actuallists. The pointer to this DATA-CELL is the parameter list item.
   2. If the actual is call-by-reference, search the NAME-TABLE for an entry containing the actual name. If an entry is found, the parameter list item is the DATA-CELL pointer in this NAME-TABLE entry. If the actual name is not found, create a NAME-TABLE entry containing the name and a pointer to a new (empty) DATA-CELL. This pointer is the parameter list item. If a jobargument contains a call-by-reference actual an error occurs with ecode = "M40" .
   3. HIf the actual is an omitted-parameter, create a new (empty) DATA-CELL.
2. Place the information contained in the formallist in the PROCESS-STACK frame.
3. For each name in the formallist, search the NAME-TABLE for an entry containing the name and if the entry exists, copy the NAME-TABLE entry into the parameter frame and delete it from the NAME-TABLE. This step performs an implicit New on the formallist names.
4. For each item in the parameter list, create a NAME-TABLE entry containing the corresponding formallist name and the parameter list item (DATA-CELL pointer). This step binds the formallist names to their respective actuals.

As a result of these steps, two (or more) NAME-TABLE entries may point to the same DATA-CELL. As long as this common linkage is in effect, an Assign, Set, or Kill of an lvn with one of the names appears to perform an implicit Assign, Set, or Kill of an lvn with the other name(s). Note that a Kill does not undo this linkage of multiple names to the same DATA-CELL, although subsequent parameter passing or New commands may.

Execution is then initiated 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, argumentless Do, 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 saved values, including any undefined states, of the variables named in the formallist are restored. See 8.2.26 for a discussion of the semantics of the Quit operation.

When calling to an externref, call-by-reference has the following additional implementation independent definition:

1. Upon return of control to M[UMPS], changes to the value of the lvn referenced by the actualname shall be as if the lvn was modified by an Assign or Set command. The exact mechanism performing this operation is unspecified.
2. The resultant events are unspecified, if the data in the M[UMPS] environment is modified while an external routine call is being made that references the modified data.
3. Local variables (see 7.1.1.2 Variables) that are not passed as parameters, will not necessarily be available to the external environment.

Copyright © Standard Documents; 1977-2024 MUMPS Development Committee;
Copyright © Examples: 1995-2024 Ed de Moel;
Copyright © Annotations: 2003-2008 Jacquard Systems Research
Copyright © Annotations: 2008-2024 Ed de Moel.

Some specifications are "approved for inclusion in a future standard". Note that the MUMPS Development Committee cannot guarantee that such future standards will indeed be published.

This page most recently updated on 13-Sep-2014, 09:20:37.

For comments, contact Ed de Moel (demoel@jacquardsystems.com)