<\body> Typed programs are of type and generated from source programs of type 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 |../../unstable/syntax/prg_syntax.mmx> contains several utility routines for the manipulation of programs. These utility routines are usually prefixed by or . The type is an abbreviation for . programs> Internally, a program is encoded by an expression tree of type (which equals ), each subtree being either of type or . Moreover, the type and the penalty associated to the program are stored in a global hashtable. <\explain> PRG> PRG> is assumed.> <\explain> GEN> TYP> Penalty> <|explain> The main accessors of programs for obtaining the underlying expression, the program type and the associated penalty. The is private, whereas the other two are public. <\explain> Boolean> Literal> program is a leaf and converting a leaf to a literal.> <\explain> PRG> Boolean> Int> PRG> <|explain> Creation of a function application (the type of the function must match the types of the arguments), testing whether a program is a compound tree, obtaining the arity of a compound tree and accessing a child of a compound tree. <\explain> <\mmx> $class (name: PRG, def: MMX): PRG <|explain> \; <\explain> <\mmx> $category (name: PRG, def: MMX): PRG <|explain> \; <\explain> <\mmx> $FUNCLASS (name: PRG, kind: Literal): PRG <|explain> This important 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 contains the name of the function or category being defined. The second parameter 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 contains avector with all fields. In the case of a function, contains a single field with the actual function declaration (and its implementation is allowed to refer to the parameters in ). The last parameter is one of the following literals: <\description> >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 of the cyclic function class as a parameter in and which calls the appropriate method of 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 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 is assumed to be empty. >Indicates that we are declaring a concrete type of a given category. The contain concrete implementations of the functionality required by the category. These functions are allowed to depend on parameters in the outer scope, whence may be non-empty. From the C++ point of view the concrete type is derived from the abstract category. The following syntactic constructs do not really correspond to primitives of the language, but useful for internal treatments. . If you don't have this file, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.> <\initial> <\collection>