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:
-
'lambda
-
Indicates that we are declaring a function.
-
'cyclic
-
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.
-
'category
-
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.
-
'constitute
-
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.
© 2009 Joris van der Hoeven
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.