|
|
||
|
Packages are highest-level structures within the model and play the same role as in popular programming languages - they allow the engineer to divide the system architecture into manageable parts. In other words, packages exist to partition the namespace into smaller compartments, where all other entities (data types, data objects and operations) are defined.
It is possible to create as many packages as is considered convenient. Package names follow the usual Wolfram convention, for example:
Above, the FMT library was imported into the current session, the new model was created and the package named “MyPackage`” was declared within the newly created system. The new package has no meaning within the Mathematica session and should not be confused with the Wolfram package system - it is an entity that exists entirely within the FMT model.
There can be many systems or models (the names “system” and “model” are equivalent) active at the same time within the same Mathematica session, but their associated declarations and definitions are not shared and do not influence each other. This means that it is possible to create another system with similarly named packages, but the packages are kept entirely separate between systems.
It is not possible to re-declare the same package and when attempted, the error message is displayed:
It is possible to declare more packages within the same system, though:
Newly declared packages are empty - that is, they contain no declarations and no definitions (still, it is possible to generate code for an empty package).
There is no notion of package hierarchy, even though package names can be constructed with the convention that suggests some relation between them:
The package “MyPackage`InnerPackage`” has no special relation to “MyPackage`” in terms of name visibility or lookup. From the FMT point of view, all packages are siblings and exist at the same level and the only visibility feature that is provided is that names defined within the package can be used within the same package without qualification. In other words, if entity something is created within package “MyPackage`”, then it can be seen as something within the same package, and as fully-qualified MyPackage`something from all packages in the same model. It is possible to define an entity with the same name in another package, which is safe, as fully-qualified names MyPackage`something and MyOtherPackage`something are guaranteed to be distinct.
It is not possible to remove the already declared package from the system and if there is a need to do so, the only supported way is to reconstruct the whole system without the unwanted packages. This should not be considered as a functional limitation, as such a feature has no analogy in any of the target programming languages. What is interesting, though, is that declaration of the package is decoupled from the definition of the entities that it contains - that is, it is not necessary (or even possible) to declare a package with all its intended members in a single step. Instead, packages are declared and then filled with definitions on a step-by-step basis, which matches the interactive workflow of Mathematica notebooks.
It is important to state that packages, even though they are used to partition the global namespace within the model, are not units of encapsulation - there is no concept of “private” part or a “private member” and all names defined within the package are visible to entities from other packages. The idea promoted within FMT is that visibility restrictions known from popular programming languages are too coarse-grained and in a formal methods platform such visibility rules can be replaced with much more elaborate rule checks and analyses of name dependency and coupling graphs.
As a result of this universal visibility between packages, it is not necessary to "import" or "include" packages in other packages - all names are visible between packages anyway. The code generators, however, properly detect the relations between packages and produce correct “with” and “include” directives in the final source code.
Previous: General conventions, next: Data types
See also Table of Contents.