Typed programs

Typed Mathemagix programs are of type PRG and generated from source programs of type MMX during the typing and disambiguation phase. Typed programs also carry a unique penalty. Subsequent optimizations, commodity rewritings and so on are all done on typed programs. Indeed, typed programs are more robust for internal treatment and more convenient because of the extra information given by the type. The file prg_syntax.mmx contains several utility routines for the manipulation of PRG programs. These utility routines are usually prefixed by $ or prg$. The type PRGS is an abbreviation for Vector PRG.

Internal representation of typed Mathemagix programs

Internally, a PRG program is encoded by an expression tree of type GEN (which equals Generic), each subtree being either of type Literal or Compound. Moreover, the type and the penalty associated to the program are stored in a global hashtable.

program: (GEN, TYP) -> PRG

program: (GEN, TYP, Penalty) -> PRG

The two main, but private, constructors of typed programs. If the penalty argument is omitted, then penalty$none is assumed.

postfix .v: PRG -> GEN

postfix .t: PRG -> TYP

postfix .p: PRG -> Penalty

The main accessors of programs for obtaining the underlying expression, the program type and the associated penalty. The postfix .v is private, whereas the other two are public.

literal?: PRG -> Boolean

convert: PRG -> Literal

Testing whether a PRG program is a leaf and converting a leaf to a literal.

postfix (): (PRG, Tuple PRG) -> PRG

compound?: PRG -> Boolean

prefix #: PRG -> Int

postfix []: (PRG, Int) -> PRG

Creation of a function application (the type of the function must match the types of the arguments), testing whether a PRG program is a compound tree, obtaining the arity of a compound tree and accessing a child of a compound tree.

Class definitions

$class (name: PRG, def: MMX): PRG

$category (name: PRG, def: MMX): PRG

$FUNCLASS (name: PRG, kind: Literal): PRG

$FUNCLASS (name: PRG, locals: PRGS, fields: PRGS, kind: Literal): PRG

This important function class construct is used for the declaration of categories and functions which depend on parameters inside some outer scope. The two argument version is for the declaration of prototypes.

The first parameter name contains the name of the function or category being defined. The second parameter locals contains the vector with all local variables in the outer scope of the declaration; every instance of the function or category contains local copies of these variables. In the case of categories, the third parameter fields contains a vector with all fields. In the case of a function, fields contains a single field with the actual function declaration (and its implementation is allowed to refer to the parameters in locals). The last parameter kind is one of the following literals:


Indicates that we are declaring a function.


Indicates that we are declaring a function which is not top-level, and which involves a mutual recursion with another function of the same type. Theoretically speaking, the recursive declaration then corresponds to the fixed point of a suitable operator. From the implementation point of view, the whole outer scope is stored in the fields of the cyclic function class. In particular, the functions themselves are implemented as members of the cyclic function class (thereby granting them access to all variables in the outer scope, including the mutually recursive functions in the same scope).

When one of the recursive functions is needed as an object in itself, we create an instance of another lambda function class, which takes the instance cyc of the cyclic function class as a parameter in locals and which calls the appropriate method of cyc on function application. This strategy is correct from the point of view of memory management: if the cyclic instance is no longer used, either directly or indirectly as part of a recursive function object, then its reference counter vanishes and the object is destroyed.


Indicates that we are declaring a category from the abstract point of view. The fields correspond to the list of all functions required by the category. Each field will be mapped to a purely virtual member function during the conversion to C++. The vector locals is assumed to be empty.


Indicates that we are declaring a concrete type of a given category. The fields contain concrete implementations of the functionality required by the category. These functions are allowed to depend on parameters in the outer scope, whence locals may be non-empty. From the C++ point of view the concrete type is derived from the abstract category.

Auxiliary constructs

The following syntactic constructs do not really correspond to primitives of the Mathemagix language, but useful for internal treatments.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License. If you don't have this file, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.