The basis for the MSH language was the MUMPS language. MUMPS was developed somewhere in the 80s of the last century, as well as many other modern languages. From the very beginning, it was developed as a language for creating large information systems, working with large distributed data. In this connection, it has some specifics. Programming in this language is somewhat different from programming in other languages. Despite its low prevalence, it has a fairly stable community of programmers developing information systems on it in different parts of the world. During its existence, MUMPS has changed little. Some elements of the language have lost relevance. And the language at the moment is somewhat archaic. I would like to have a more modern language like MUMPS. For this purpose, the MSH language was created. Some MSH concepts are different or absent in the MUMPS language. This material was written mainly for the audience of MUMS programmers, but it may be interesting to others.

Constants

There are no constants in MUMPS. In MSH they are introduced. But due to the specifics of the language, they cannot exist in the form of immutable variables of the program execution time. Therefore, in MSH they are introduced as compile-time objects. Something like define the C language in the most simplified form. At the time of translation of the MSH language into Pi, the virtual machine code replaces all the constants in the source text with their values. That is, they are no longer in the Pi code. Constants can be used as variable values, as an index, or as a variable name. Command format: Constant nameConst = valConst <, nameConst = valConst>; Only a constant can be to the right of the equal sign, expression is not allowed. The name of the constant must be unique and must not overlap with the names of variables.

Variables

In MUMPS, variables are stored in a wooden structure, whether global or locale. True, globals in MUMPS have a slight difference - shortened syntax. There is no abbreviated syntax in MSH. Storing data in the form of only a tree allows you to unify data access. You can write programs to process any data tree. But in programs, you often have to work with various intermediate values ​​and store them in a tree not efficiently. Access to the tree always entails additional costs, no matter how we optimize this access. In MSH, data can be stored both in a wooden structure and in a one-dimensional array. It is better to store intermediate data in a one-dimensional array, although any data can be stored. Access to the array is much faster than to the tree. The tree store the so-called discharged data. That is, only existing vertices are stored in the tree. For example, we have a tree [1] [5] [78]. Only these peaks will be stored in a tree. The array stores all intermediate values. For example, we created 78 elements in an array of $ 78. All elements in this array will be created up to 78. If we create a tree, then an empty array is also created and vice versa, if an array is created, an empty tree is also created. But this of course applies to the current MSH implementation. The visibility of variables in MUMPS has its own characteristics. What are called globals in other languages ​​in MUMPS is access to databases. But locales are analogous to variables in other languages. Well, with the globals, everything is clear. This is external data and it is available both from any task of this application, and from other applications. They are stored in the form of files and, as a rule, several globals in one file. In MSH, in general, everything is the same except for one point. Each global is stored in a separate file. And more precisely, in several files of the same directory. This point is significant from the technological point of view of building an information system. And one more remark. Globals in MSH are synchronized in circulation. This means that they can be accessed simultaneously from different tasks without additional synchronization. Now we’ll deal with locales in more detail. In general, a locale in MUMPS is a top-level global variable in the sense of the C language. An analog to variables from a heap in the C language, in MUMPS is not. But there is an analogue of automatic variables of the C language. These are the locales listed (or not listed), depending on the form of the command, in the New command. The scope of such locales from the New command to the Quit block completion command. The original solution, of course, is due to the nature of MUMPS and the lack of variable declarations in it. In my opinion, the global scope of locales by default is a controversial decision, although not fatal. In MUMPS, where I mainly work directly with globals, there are not so many local variables and name conflicts are not frequent, although they do happen. But still this is not convenient when programming. MSH takes a different approach. New is not here. And the localization of variables is prefixed. Variables prefixed with% are localized inside the job. Variables prefixed with ^ tmp are localized within the application. Variables without these prefixes are localized inside the Do block. This applies equally to trees and arrays. In my opinion, the global scope of locales by default is a controversial decision, although not fatal. In MUMPS, where I mainly work directly with globals, there are not so many local variables and name conflicts are not frequent, although they do happen. But still this is not convenient when programming. MSH takes a different approach. New is not here. And the localization of variables is prefixed. Variables prefixed with% are localized inside the job. Variables prefixed with ^ tmp are localized within the application. Variables without these prefixes are localized inside the Do block. This applies equally to trees and arrays. In my opinion, the global scope of locales by default is a controversial decision, although not fatal. In MUMPS, where I mainly work directly with globals, there are not so many local variables and name conflicts are not frequent, although they do happen. But still this is not convenient when programming. MSH takes a different approach. New is not here. And the localization of variables is prefixed. Variables prefixed with% are localized inside the job. Variables prefixed with ^ tmp are localized within the application. Variables without these prefixes are localized inside the Do block. This applies equally to trees and arrays. But still this is not convenient when programming. MSH takes a different approach. New is not here. And the localization of variables is prefixed. Variables prefixed with% are localized inside the job. Variables prefixed with ^ tmp are localized within the application. Variables without these prefixes are localized inside the Do block. This applies equally to trees and arrays. But still this is not convenient when programming. MSH takes a different approach. New is not here. And the localization of variables is prefixed. Variables prefixed with% are localized inside the job. Variables prefixed with ^ tmp are localized within the application. Variables without these prefixes are localized inside the Do block. This applies equally to trees and arrays.

Объекты.

There are no objects in MUMPS. But OOP is ubiquitous. The bulk of modern programming languages ​​one way or another supports OOP. MSH is no exception. In order for OOP to exist, the language must have objects for starters. In general, a description of an object consists of a declarative part and a implementation part. MSH does not support variable declarations, which means that there will be no declarative part of the object description. There is an object description in MSH as part of the implementation. In MUMPS, program code is presented as software modules. Entry points in the module are routines and functions. The software module is in MSH and is taken as a description of an object (class). Module labels are the entry points of this module. Entry points in this case are public get properties of this class. The public set properties of this class will be the same entry point as get modified with a specific character. As such, the dot symbol “.” Is selected in MSH. In addition to get and set access, a property in MSH also has a Kill operation — deleting a property. In this case, the name of the properties is modified with the prefix "..". Class inheritance in MSH is plural and implemented using the Extend command. The classes listed in this command in order are the ancestors of this class. During program execution, when accessing an object property, its description is first searched in the source module and then in the modules listed in the Extent command in the order they are followed. An earlier position of a module in a team gives it a higher priority. Protected properties are implemented using the% this system property. Objects in MSH can only be in the tree. Only primitive data types can be stored in the array. Class methods are also entry points in the class module. Objects are created using the standard% new property. For example, we have the Person class with the Age property. The class module has entry points “Age” and “.Age.” In the variable [1,2], create an object. Set [1,2].% New = Person; Access the Age property of the Person object by record. Set [1, 2] .Age = 50; Access to the Age property of the Person object on reading.Set $ ​​1 = [1,2] .Age; The translator converts these commands into calls to subroutines. But this is not the only way to access properties. By recording, the Age property can also be accessed through the .Do [1,2] .Age (50) method; in MSH, the module performs a dual role. In addition to the class module, it can be interpreted as a program module. In this case, entry points are referred to as subprograms. Suppose there is an ABC label in the Person module. Then you can refer to it as a program. True, in this case, the% this variable will be empty. Do Person.ABC (125, D, 25.6); So you can organize class methods.

События.

Another effective programming paradigm is events. As a rule, programming languages ​​do not contain event processing tools. They are usually placed in standard libraries. In MUMPS, event processing is in its infancy and comes down to error handling. In MSH, events are included in the language. Events can be as system generated by the system. So the user generated by the user using the EventTrap command. The arguments to this command are passed to the handlers of this event. The EventCall command assigns a program to the event handler. When the event occurs, the current task will be interrupted and the handler program will be executed in the new Do block. As if at this point the Do command met with a call to this handler. This means that the local variables of the running program in the event handler will be unavailable. The EventWait command stops the execution of the current program and waits for the event to occur. When an event occurs, the current program continues to work and from that moment on, the passed arguments become available in the program. A new Do block is not created and therefore all local variables of this Do block are available after the EventWait command. If the event occurred before the EventCall and EventWait commands appeared. That event will be handled by the first EventCall or EventWait command encountered. After processing, the event is deleted. The EventDelete command deletes an event along with handlers. A new Do block is not created and therefore all local variables of this Do block are available after the EventWait command. If the event occurred before the EventCall and EventWait commands appeared. That event will be handled by the first EventCall or EventWait command encountered. After processing, the event is deleted. The EventDelete command deletes an event along with handlers. A new Do block is not created and therefore all local variables of this Do block are available after the EventWait command. If the event occurred before the EventCall and EventWait commands appeared. That event will be handled by the first EventCall or EventWait command encountered. After processing, the event is deleted. The EventDelete command deletes an event along with handlers.