When Peter D. Mosses introduced action semantics in the 1990's, it was considered as a formalism to describe programming languages. From the description written in action semantics, not only was the syntax of the programming language rigorously defined, but also its semantics. Because it is well-defined, analysis, verification, test and code-generation can be done directly from the descriptions. The results of the code-generation, of course, are compilers for specific programming languages.
An action semantics description, contrary to the one written in denotational semantics, has an informal appearance, which looks like the natural English language. It is this appearance that raises a lot of arguments and criticism. However, it is fact that this appearance does not sacrifice any formality in its semantics, because it is rigorously defined.
There are three kinds of semantic entities in action semantics: actions, data and yielders. Actions, the most important part, define the operations that can be performed on data and yielders. An execution of actions usually results in the evaluation of yielders and the manipulation/modification of data. Data are cells which store primitive data entities (i.e. byte, int, float, char) and objects (defined by classes). They can be located in the main memory, hard disk or any other type of storage. Yielders are a kind of expression whose evaluation yield data. Note that yielders only yield data but never change them. Data can only be changed by execution of actions, whose semantics, as discussed above, is well-defined.
Now comes the question: what an action semantics description of programming language looks like. In his early proposal, Peter D. Mosses separates the description into three modules: abstract syntax, semantic functions and semantic entities. Each module may comprise several files. There is no general rule on the division of a module into files, as long as the description is clear and the modularity is kept.