The MUMPS Development Committee meets several times in a year to discuss proposals to enhance the M Technology ANSI standards, including the M Language standard. The MDC last met in June and plans to meet again in September 1998. Several M Computing readers who were not able to attend the MDC meetings are, nevertheless, interested in some of the specifics of these proposals. We'll try to, very briefly, describe a few of them in this column in each issue of M Computing.
The MUMPS Development Committee plans to begin the canvass process in September 1998 to revise several of the current M Technology ANSI standards. If you would like to participate in the canvass process to seek ANSI approval, contact the MDC Secretariat at the MTA office to be put on the preliminary canvass list.
An MDC Type A proposal is one that will be included in the next revised version of the MDC standard document. The MDC standard is the draft standard that will be canvassed for ANSI approval as a revision of the current ANSI standard document.
This is a brief summary of one of the recent proposals that the MDC has passed to MDC Type A status. Not all the sections of the proposal, or the formalization of the actual changes proposed for the current ANSI standard, have been included.
Justification of the proposed change:
Much of modern programming is based on event-driven programming. Graphical
user interfaces require event driven programming. Messaging techniques in
object oriented programming require event driven programming. Network
protocols requires event driven programming. The ability to handle events in
both synchronous and asynchronous paradigms is now essential.
There are two models for event processing: synchronous and asynchronous. In the synchronous model, often used for graphical user interfaces, the control of the program is turned over entirely to the incoming events. The program runs an event loop which processes the incoming events one at a time. When each event is processed, the event loop waits for the next event. No events are processed except when control is in the event loop-events are not interruptable. This is the model used in the M Windowing API.
In the asynchronous model, program control follows normal behavior until an event occurs. At that time normal flow is interrupted and the event handler processes the event. When the event has been processed the program control returns to the point at which it was interrupted. Because not all sections of processing can be interrupted by all types of events, it is usually necessary to allow selected events to be blocked from interrupting critical sections of programs. When the block is removed, the pending events are processed.
Existing practice in the area of the proposed change:
The M Windowing API introduced the ESTART and ESTOP commands and the ^$EVENT
structured system variable to handle event processing in a synchronous
model. These commands allow the windowing system to respond to a number of
special events related to user interaction with the windowing system and to
other occurrences (e.g., timers).
This Error Processing proposal provides a specialized case of asynchronous event processing. Because error conditions can be intentionally generated by setting $ECODE non-empty, this has been used in some cases to provide event processing. This can be ungainly, however, as error processing was not designed to handle generalized event processing.
General description of the proposed change:
The ESTART and ESTOP commands of the M Windowing API standard are added to
the M Language standard with little change. The ETRIGGER command is also
added, but with some (backwards compatible) modifications. In addition, four
additional commands (ASTART, ASTOP, ABLOCK, and AUNBLOCK) are added to
handle asynchronous event processing.
This Event Processing proposal provides a mechanism by which a process can execute specifiable commands in response to some occurrence outside the normal program flow. Event processing can be done using either a synchronous model or an asynchronous model. Synchronous event processing is enabled by issuing the ESTART command, and disabled by issuing the ESTOP command. Asynchronous event processing is enabled by issuing the ASTART command, and disabled by issuing the ASTOP command. It is possible to temporarily block asynchronous events from being processed during critical program sections by using the ABLOCK command. This temporary block is released by using the AUNBLOCK command. Events can be generated by running processes using the ETRIGGER command.
Impact on existing user practices and investments:
No existing code will need to be changed as a result of this proposal. This
change is compatible with the M Windowing API standard. This Event
Processing proposal will facilitate networking, communications, and other
applications that require event processing capabilities.
One vendor indicated that much of the underlying effects of this proposal already exist in their products to handle the process control inherent in M. They indicated further that they expect that this is the case with all M vendors.
"The above MDC specification has been approved by the MUMPS Development Committee but it may be a partial specification that relies on information appearing in many parts of the MDC standard. This specification is dynamic in nature, and the changes reflected by this approved change may not correspond to the latest specification available. Because of the evolutionary nature of MDC specifications, changes are likely to occur in the specification released prior to a complete republication of the MDC standard."
To keep current on all details of the proposals that the MDC is considering you can subscribe to the MDC document mailings through the MTA. A one-year subscription costs $120 plus shipping and handling.