You are on page 1of 12

Macros as Multi-Stage Computations:

Type-Safe, Generative, Binding Macros in MacroML

Steve Ganz  Amr Sabryy Walid Tahaz

Computer Science Computer Science Department of Computer
Department Department Science
Indiana University Indiana University Yale University

ABSTRACT to de ne new language onstru ts or shorthands. Many

Ma ros have traditionally been viewed as operations on syn- tasks an be a hieved using su h ma ro systems, in lud-
tax trees or even on plain strings. This view makes ma ros ing onditional ompilation, on guration of appli ations to
seem ad ho , and is at odds with two desirable features of parti ular environments, templates for parameterized om-
ontemporary typed fun tional languages: stati typing and putations, and even the implementation of domain-spe i
stati s oping. At a deeper level, there is a need for a simple, languages. Yet ma ros are not part of the standards for
usable semanti s for ma ros. This paper argues that these the mainstream stati ally-typed fun tional languages su h
problems an be addressed by formally viewing ma ros as as ML and Haskell.
multi-stage omputations. This view eliminates the need for
suspi ious freshness onditions and tests on variable names, So, why are they ignored?
and provides a ompositional interpretation that an serve
as a basis for designing a sound type system for languages Often, ma ros are onsidered to be either an implementa-
supporting ma ros, or even for ompilation. tion detail (and therefore not interesting) or, a form of bla k
magi (and therefore should be kept at bay). Both these
To illustrate the proposed approa h, we develop and present stands are unfounded. First, it is a mistake to give ma ros
Ma roML, an extension of ML that supports inlining, re ur- (or even inlining pragmas) the status of a ompiler dire tive
sive ma ros, and the de nition of new binding onstru ts. that the implementation may or may not take into a ount:
The latter is subtle, and is the most novel addition in a ma ros a e t the semanti s of programs (see Se tion 2). Se -
stati ally typed setting. The semanti s of a ore subset ond, the absen e of a ma ro fa ility almost invariably for es
of Ma roML is given by an interpretation into MetaML, programmers to resort to ad ho solutions to a hieve the
a stati ally-typed multi-stage programming language. It is same fun tionality.
then easy to show that Ma roML is stage- and type-safe:
ma ro expansion does not depend on run-time evaluation, There are also te hni al diÆ ulties: ma ros are hard to spe -
and neither \goes wrong" in the usual sense. ify from rst prin iples. Ma ro designers often nd them-
selves for ed to des ribe ma ros at the level of program text
1. INTRODUCTION or syntax trees, and to address the inevitable hygiene prob-
Most real programming language implementations provide lems and s oping problems using gensym (or freshness on-
a ma ro fa ility that an be used to improve either perfor- ditions) and many unintuitive equality and inequality tests
man e or expressiveness, or both. In the rst ase, ma ros on variables names [19℄. Not only are su h low-level spe i-
are usually used for inlining or unfolding parti ular fun - ations hard to ommuni ate (making ma ros a quire the
appearan e of being unsystemati ), they are also at odds
tion alls. In the se ond ase, ma ros are usually used with stati typing: if variable names and their binding re-

This work was supported in part by the National S ien e lationships are not known until after ma ro expansion, it
Foundation under grant CDA-9312614. be omes hard (if not impossible) to type- he k ma ros be-
This material is based upon work supported by the Na- fore expansion and evaluation start.
tional S ien e Foundation under Grant No. CCR-0196063.
z Funded by sub ontra t #8911-48186 from Johns Hopkins
This paper argues that ma ro systems an be viewed for-
University under NSF agreement Grant # EIA-9996430. mally and usefully as multi-stage omputations. Multi-stage
programming languages (in luding two-level languages [28,
16℄, multi-level languages [13, 14, 15, 8, 7℄, and MetaML
[41, 39, 5℄) have been developed pre isely to provide pre ise
and usable models of su h omputations that o ur in mul-
tiple distin t stages. Over the last few years, the study of
MetaML and related systems has not only resulted in a good
understanding of the types and semanti s of multi-stage sys-
tems, but has also solved, on e and for all, some of the hard
problems (freshness onditions, typing) in ma ro systems.
Formalizing ma ros as multi-stage omputations also em- as data, su h as in early LISP systems or in C. The
phasizes that the te hni al problems asso iated with ma ros S heme ommunity has had a substantial role in re -
are genuine: spe ifying the denotational semanti s of ma ros ognizing and addressing this problem and promoting
involves the same advan ed tools as the denotational se- the notion of hygieni ma ro expansion [19, 9℄. More
manti s for two-level, multi-level, and multi-stage languages re ently, there have been more sophisti ated propos-
(su h as fun tor- ategories or topoi [24, 25, 4℄). A denota- als, like higher-order abstra t syntax (HOAS) [33, 21,
tional semanti s has parti ular relevan e to realisti ompil- 17, 12℄, and FreshML [34℄. The key ontribution of all
ers, whi h invariably involve a translation phase. A om- these proposals is to provide a means to express the
positional (denotational) semanti s is generally one of the fa t that \programs are not just data."
most helpful kinds of semanti s in developing and verifying
su h ompilers [30℄.  Ma roML does not allow ma ros that inspe t or take
apart ode (i.e., analyti ma ros ). This restri tion
While this paper demonstrates that MetaML is a good meta- seems ne essary to maintain stati typing. Instead all
language for de ning ma ros, MetaML is not the ideal lan- ma ros in Ma roML are limited to onstru ting new
guage for writing ma ros: it does not have support for de n- ode and ombining ode fragments (i.e., generative
ing new binding onstru ts. In addition to di tating and ma ros ). This paper presents a number of examples
ontrolling inlining, ma ros are often used to abstra t om- that suggest that many useful tasks an be a om-
mon synta ti patterns in programs. In a language with plished using su h stati ally typed generative ma ros.
higher-order pro edures, espe ially a lazy language, some of
these abstra tions an be expressed (maybe with a loss of Espe ially the rst point is inspired by multi-stage language,
eÆ ien y) using fun tions. But many of the synta ti pat- but to an extent, so are the other two. A key issue that arises
terns over whi h one wants to abstra t would need to bind in the presen e of ma ros that de ne new binding onstru ts
variables. Constru ts that bind variables are not dire tly is the handling of onversion. While it is not lear how this
expressible using fun tions. For example, overloading an ex- problem an be addressed in the untyped setting, it is also
isting binding onstru t su h as the do-notation of Haskell addressed by the type system. As su h Ma roML tries to
to allow re ursive bindings annot be expressed using fun - a hieve a balan e between being an expressive ma ro system
tions, and requires a hange to the ompiler [10℄. and being a ma ro system that we an reason about.
Ma roML: This paper presents an expressive, typed lan- Organization : Se tion 2 introdu es Ma roML by a series of
guage that supports generative ma ros. This language, all- motivating examples, and dis usses the issue of alpha equiv-
ed Ma roML, is de ned by an interpretation into MetaML, alen e in the presen e of ma ros that an de ne new bind-
and an express (both simple and re ursive) inlining and ing onstru ts. Se tion 3 reviews the MetaML syntax, type
the de nition of new binding onstru ts. A key design goal system, and semanti s. Se tion 4 presents the main te h-
for Ma roML is that it be a onservative extension [11℄ of ni al ontribution: a ompositional interpretation of Core
ML. This implies that its type system should in lude all Ma roML into MetaML that provides a semanti s that is
well-typed ML programs. It should also not break the rea- both exe utable and reasonably easy to ommuni ate. Nei-
soning prin iples for ML programs, su h as and v on- ther the Ma roML language nor the translation use any op-
version. We also want the language to remain stati ally erations nor side- onditions to generate fresh names. In-
typable. Given that our goal is a onservative extension of stead this is relegated to the semanti s of the target language
ML, there are some notable points about what Ma roML is of the translation. The target language itself, MetaML, has
designed not to do: an operational semanti s de ned using nothing but the stan-
dard notion of substitution. The translation is shown to
produ e only well-typed MetaML terms thus providing a
 Ma roML does not blur the distin tion between pro- type safety result for Ma roML. Se tion 5 onsiders several
grams and data. Although many appli ations natu- extensions to Core Ma roML and dis usses implementation
rally view programs as data, there is a fundamental issues. Se tions 6 and 7 dis uss related work and on lude.
distin tion between the two. While both programs
and data an be represented (using, e.g., natural num- 2. MACROML BY EXAMPLE
bers, S -expressions), the notions of equality asso iated In this se tion, we use a sequen e of examples to intro-
with ea h one (synta ti and semanti equality, respe -
tively) annot and should not be mixed. Furthermore, du e the basi issues motivating and governing our design
internalizing the two notions into a language, while of Ma roML. Ea h example is followed by a summary of the
still enfor ing the distin tion between the two is non- basi semanti on erns that it raises.
trivial [22, 44, 39℄. For better or worse, it is relatively
easy to pi k one or the other, that is, to either have 2.1 Simple Inlining: A First Attempt
synta ti equality or semanti quality everywhere. In Consider the following ode ex erpt, where the fun tions
Ma roML, we hoose to allow only semanti equality in iterate and shift_left have the expe ted meaning:
the language and we avoid introdu ing synta ti equal-
ity (on programs) by not introdu ing any re e tive or let val word_size = 8
ode-inspe tion apabilities into the language. in ... iterate shift_left word_size ... end
 Ma roML does not introdu e a idental dynami s op-
ing and/or variable apture. These problems gener- Here, word_size is used purely for reasons of larity and
ally arise from an overly simplisti view of programs maintainability in the sour e ode, and most implementa-
tions are likely to inline it produ ing: The de lared operators $ and ?, read \delay" and \for e,"
respe tively, implement a simple variant of Okasaki's pro-
posal for suspensions [29℄. There are two notable features
... iterate shift_left 8 ... about this example. First, we annot de ne $ as a fun tion
sin e the evaluation of $ e' should not allow the premature
But in a general situation where word_size is bound to a evaluation of e'. Thus, this is a genuinely useful appli ation
more ompli ated expression like x+4 or an expression whose of a ma ro system. Se ond, ma ro expansion should not al-
evaluation might have side-e e ts like 1/x, the situation is low the binding o urren e of x in the ma ro de nition to
more deli ate. Some ompilers might inline x+4 and some a idently apture free o urren es of x in ma ro arguments.
might not. And no ompiler is at liberty to inline expressions
with e e ts: this is lear in a language like ML, but it is also Semanti s: The semanti s of fun tional inlining involves two
the ase in \pure" languages like Haskell where ompilers substitutions. First, the argument of the ma ro appli ation
must restri t inlining when dealing with built-in monadi is substituted into the body. Given that we are using the
e e ts [36, 1℄. Compilers also annot be left to inline or not standard notion of substitution, the variable x in the above
inline at will when we are about resour e behavior [27℄. example annot o ur in the expression bound to the vari-
able e. Se ond, the resulting ma ro body is substituted
Sin e inlining a e ts not only the performan e but also the ba k into the ontext of appli ation, again using the stan-
semanti s of ML programs, we elevate it to a full language dard notion of substitution. In our example, the expres-
onstru t with on rete syntax, typing rules, and formal se- sion fn x => $ (tl x) expands to fn x => fn x' => tl x
manti s. In Ma roML, programmers an require inlining of where x' is a freshly generated name (with a base name x
an expression using a new variant of let-expressions alled only to hint to its sour e).
let ma . For example, the fragment:
This example demonstrates another key feature of ma ro
systems: be ause ma ro alls an o ur under binders, the
let ma word_size = raise Unknown_size semanti s requires evaluation under binders. This is signif-
in ... iterate shift_left word_size ... end i ant be ause evaluation under a binder generally involves
manipulating open ode whi h is signi antly more ompli-
ated [41, 26, 38℄ than the restri tion to dealing with only
di tates that, even though raise Unknown_size is not an losed terms imposed by most semanti spe i ations and
ML value, we want it inlined, produ ing: implementations of languages (whether CBV, CBN, or all-
... iterate shift_left (raise Unknown_size) ...
2.3 Recursive Macros
What if we wish to perform more omputations during ma ro
Semanti s: The semanti s of this kind of inlining is simply expansion? Consider the lassi power fun tion pow:
the standard apture-avoiding substitution of a variable by
an expression [6, 2℄. Unfortunately, while this is a good
example of the \essen e of inlining," introdu ing inlining in let fun pow n x =
this fashion (through the mere o urren e of a variable) an if n = 0 then 1 else x * (pow (n-1) x)
interfere with established reasoning prin iples for all-by- in pow (2*3) (5+6) end
value (CBV) languages. For example, in a standard CBV
al ulus [35℄, K 5 x is observationally equivalent to 5 sin e
variables are values. But in the ontext: If we repla e the fun keyword by ma , ma ro expansion
goes into an in nite loop, whi h is probably not the de-
sired behavior. What happens? Intuitively, the ma ro all
let ma x = raise Error in ... end pow (2*3) (5+6) expands into :

these two terms behave di erently, be ause, ontrary to if 2*3 = 0 then 1 else (5+6) * (pow (2*3-1) (5+6))
the usual assumption about CBV variables, x is repla ed
by a non-value. To retain the established reasoning prin-
iples of CBV languages, we restri t all uses of ma ros in whi h itself expands into :
Ma roML to be synta ti ally non-values (e.g., appli ations,
let-expressions, et ). if 2*3 = 0 then 1
else (5+6) * (if (2*3-1) = 0 then 1
2.2 Functional Inlining else (5+6) * (pow ((2*3-1)-1) (5+6)))
Ma ros that take arguments are just as useful if not more
useful than simple inlining. Their form (as appli ations) also
provides the added advantage that they do not interfere with and the expansion goes on inde nitely. Ma ro expansion
the established semanti s of CBV languages. Consider: an only terminate if the if-expression is evaluated dur-
ing expansion, and not re onstru ted as part of the result.
To require the exe ution of the if expression during ma ro
ma $ e = fn x => e expansion, we must expli itly indi ate that n is an early pa-
ma ? e = e () rameter, rather than a regular ma ro parameter (whi h we
all late ), and annotate the term to distinguish among early Semanti s: A key insight behind this aspe t of our proposal
and late omputations. The intended pow ma ro an now is to allow the user to only de ne new binding onstru ts
be written as: that follow the patterns of existing binding onstru ts, su h
as lambda abstra tions, value de larations, and re ursive
de larations. In these binding onstru ts every o urren e of
let ma pow ~n x = a variable an be immediately identi ed as either a binding
~(if n = 0 then <1> else <x * ~(pow (n-1) x)>) o urren e or a bound o urren e. The semanti s of our
in pow ~(2*3) (5+6) end proposal is designed to re e t this distin tion. But even
when this distin tion is taken into a ount, equivalen e
The two onstru ts es ape ~e and bra kets hei are borrowed is still subtle. For example, the de nition above annot be
dire tly from MetaML, and work as follows: the rst on- written into:
stru t \es apes" from the \ma ro expansion mode" to reg-
ular ML evaluation to perform a omputation; the se ond ma (let seq x = e1 in e2 end) =
onstru t interrupts regular evaluation to return a result to $(let val y = ?e1 in ?e2 end)
the \ma ro expansion mode." The expansion of the ma ro
all above now yields:
with the justi ation that \y is a binding o urren e, and
(5+6) * (5+6) * (5+6) * (5+6) * (5+6) * (5+6) * 1
it does not o ur in the body ?e2." The problem here is
that there are in fa t two di erent binding o urren es of
the variable x, and ea h one of them is of a di erent nature.
Semanti s: The need for introdu ing the bra kets and es- In essen e, the rst one (in the parameter of the ma ro)
ape onstru ts is dire tly related to the need to have a says that \there is a variable, let's all it x, whi h an o ur
well-spe i ed order for evaluating various sub-expressions. free in the expression bound to e2". Be ause of this, the
In parti ular, with re ursion, it be omes lear that there use of the variable name x in the se ond de laration now
are two di erent kinds of omputations: early ones and late has spe ial meaning. In essen e, the se ond de laration now
ones. The need to intermix these two kinds of omputation says \use x lo ally as a normally variable name, but make
is what requires a more substantial type system than usual. sure that it is treated in the output of the ma ro as the
In parti ular, we must enfor e what is alled ongruen e in binding o urren e for the x in e2."
the partial evaluation literature: a well-formed multi-stage
omputation should not ontain an early omputation that The type system for Ma roML addresses this issue through
depends on the result of a late omputation [18℄. A simple two me hanisms: rst, spe ial type environments are used
example of the kind of program that the type system has to to keep tra k of the de larations of ma ro parameters, and
reje t is: most importantly, the bindee parameters like e2 above. Se -
ond the type of these bindee parameters will expli itly arry
around the name of the binder parameter x, whi h omes
let ma f b n = ~(if b=0 then <n> else <n+1>) from the rst de laration of x. The se ond de laration of
in fn a => fn m => f a m end x itself is in fa t a ompletely normal de laration. With
this typing information, it is possibly to reje t the lo al re-
The ma ro argument a is needed during ma ro expansion pla ement of x into y as above. It is important to note the
but, being a run-time variable, it is unbound at that time. di eren e between this me hanism and the lassi \a iden-
tal dynami s oping:" the dependen y on a \free" variable
2.4 Defining New Binding Constructs is re e ted expli itly in the type. Essentially the same prin i-
We now ome to one of the most novel features of Ma roML: ple underlies the re ent proposal for impli it parameters [20℄.
the ability to de ne new binding onstru ts in the typed We know that the type system provides an adequate solution
setting. Let us say that we are using the ma ros $ and ? for to the problem of onversion in the sour e program be-
suspensions to implement a notion of a omputation [23℄. ause the type system guarantees that well-typed Ma roML
We de ne a suitable monadi -let for this setting as follows: programs an be translated to MetaML programs, and in
the latter, renaming is ompletely standard, even in the
untyped setting.
ma (let seq x = e1 in e2 end) =
$(let val x = ?e1 in ?e2 end) At this point, the reader may wonder \how are variables
passed around in Ma roML?" We return shortly to this ques-
tion in Se tion 4.
The de nition introdu es a new binding onstru t let seq
whi h expands to the ore binding onstru t let val. For
Ma ro systems introdu e a stage of omputation that should
happen before the traditional stage of program exe ution.
let seq y = f $7 in g y end Early omputations during this new stage in lude ma ro
expansion as well as various other traditional omputations
expands to: (e.g., onditionals, appli ations, et ).
As mentioned in the introdu tion, multi-level languages have
$(let val x = ?(f $7) in ?(g x) end) been developed to model su h kinds of staged omputation.
x : tn 2 ; x : tn1 `n e : t2 `n e1 : t2 ! t `n e2 : t2
`n x : t `n x:e : t1 ! t2 `n e1 e2 : t
; f : (t1 ! t2 ! t3 ! t)n ; x1 : tn1 ; x2 : tn2 ; x3 : tn3 `n e1 : t
; f : (t1 ! t2 ! t3 ! t)n `n e2 : t4 `n+1 e : t `n e : hti + `n e : hti
`n letre f x1 x2 x3 = e1 in e2 : t4 `n hei : hti `n+1 ~e : t `n run e:t

Figure 1: MetaML Type System

Multi-level languages o er onstru ts for building and om- the same variable name. We write x : tn 2 when x : tn is
bining ode, often in a typed setting. Multi-stage languages a sub-term of a valid .
are multi-level languages that provide the user with a means
of exe uting the generated ode. The notion of \ ode" de- The rules of the type system are presented in Figure 1. The
s ribed here is an abstra t one. For example, it has been rst four rules of the type system are standard, ex ept that
proven that beta-redu tions are sound inside this notion of the level n of ea h term is passed around everywhere. Note
ode [39℄. This means that ode in su h systems is never in- that in the rule for lambda (and re ursive fun tions), we
spe ted (nor observed) synta ti ally. An alternative, equally take the urrent level and use it as the level of the bound
valid way of thinking about these languages, therefore, is variable when we add it to the environment.
that they provide ne ontrol over the evaluation order [41,
40, 37℄. The rule for bra kets says hei an have type hti when e has
type t. In addition, e must be typed at level n + 1, where n
A premier example of a stati ally-typed, fun tional, multi- is the level for hei. The level parameter is therefore ounting
stage language is MetaML. In addition to the normal on- the number of \surrounding" bra kets. The rule for es ape
stru ts of a fun tional language, MetaML also has three does basi ally the onverse. Note, therefore, that es apes
onstru ts for building, eÆ iently ombining, and exe ut- an only o ur at level 1 and higher. Es apes are supposed
ing ode. These three onstru ts are bra kets hei,es ape ~e, to \undo" the e e t of bra kets.
and run run e. For the purposes of our study here, we use
the following small MetaML language as our multi-stage lan- Finally, the rule for run e is rather subtle: we an run a term
guage: of type hti to get a value of type t. However, we must be
areful to note that the term being run must be typed under
e 2 EMeta ::= x j x:e j e e the environment + , rather than simply . We de ne +
j letre f x1 x2 x3 = e1 in e2 as having the same variables and orresponding types as ,
j hei j ~e j run e but with ea h level in remented by 1. Without this (rather
We have restri ted the number of arguments of re ursive subtle) adjustment the type system is unsafe [40, 26, 38℄.
fun tions to three, only for simpli ity.
Figure 2 de nes the big-step semanti s for MetaML. There
We present a type system for this language with the follow- are a number of reasons why the big-step semanti s for
ing types: MetaML [26, 40℄ is an instru tive model for the formal study
of multi-stage omputation: rst, by making \evaluation un-
t 2 TMeta ::= nat j t ! t j hti der lambda" expli it, this semanti s makes it easy to illus-
Here nat is the type for natural numbers, used as an example trate how a multi-stage omputation often violates one of the
of various base types. In this paper, we have omitted giving basi assumptions of many works on programming language
onstru ts that work on this type be ause their treatment semanti s, namely, the restri tion to losed terms. Se ond,
is trivial, and spa e is limited. Fun tion types as usual have by using just the standard notion of substitution [2℄, this se-
the form t ! t. The MetaML ode type is denoted by hti. manti s aptures the essen e of stati s oping, and there is
In this se tion we present a sound type system for MetaML. no need for using additional ma hinery to perform renaming
The soundness of this type system is studied and estab- at run-time.
lished elsewhere [40, 26, 38℄. While this type system is not The big-step semanti s for MetaML is a family of partial
the most expressive type system available for MetaML (see n
fun tions ,! : EMeta ! EMeta from expressions to \an-
for example [26, 38, 5℄), it is simple and suÆ ient for our
purposes here. swers," indexed by a natural number n (the level). Taking
n to be 0, we an see that the rst two rules orrespond to
The judgments of the type system have the form `n e : the rules of a CBV lambda al ulus. The rule for run at
t, where n is a natural number alled the level of a term. level 0 says that an expression is run by rst evaluating it
The role of the notion of level is explained below where we to get an expression in bra kets, and then evaluating that
onsider the type rules and the semanti s for bra kets and expression. The rule for bra kets at level 0 says that they
es ape. The ontext is a map from identi ers to types and are evaluated by rebuilding the expression they surround at
levels, and is represented by the following term language: level 1. Rebuilding, or \evaluating at levels higher than 0,"
is intended to eliminate level 1 es apes. Rebuilding is per-
::= [℄ j ; x : tn formed by traversing the expression while orre tly keeping
tra k of levels. Thus rebuilding simply traverses a term until
In any valid , there should be no repeating o urren es of
e1 ,! x:e
e2 ,! e3 F  x1 :x2 :x3 :e1 [f := letre f x1 x2 x3 = e1 in f℄
0 0
e[x := e3 ℄ ,! e4 e2 [f := F ℄ ,! e3
0 0 0
x:e ,! x:e e1 e2 ,! e4 letre f x1 x2 x3 = e1 in e2 ,! e
0 0
e1 ,! he2 i e2 ,! e3
e1 ,! e2
e1 ,! e3 e2 ,! e4
run e1 ,! e3
x ,! x
x:e1 ,! x:e2
e1 e2 ,! e3 e4
n+1 n+1
e1 ,! e3 e2 ,! e4
letre f x1 x2 x3 = e1 in e2 ,! letre f x1 x2 x3 = e3 in e4
e1 ,! e2
e1 ,! e2
e1 ,! e2
e1 ,! he2 i
he1 i ,! he2 i
n+1 n+2 1
run e1 ,! run e2 ~e1 ,! ~e2 ~e1 ,! e2

Figure 2: MetaML Big-Step Semanti s

a level 1 es ape is en ountered, at whi h point normal (level We are now at a point where we an pre isely de ne and
0) evaluation fun tion is invoked. The es aped expression interpret our ma ro language. We present the syntax, type
must yield a bra keted expression, and then the expression system, and semanti s of the ore of Ma roML ( alled Core
itself is returned. Ma roML). The language has the usual expressions for a
CBV language, augmented with the previously-motivated
Interesting examples of MetaML programs an be found in let ma - onstru t for de ning ma ros, and the ~e and hei
the literature [41, 38, 37℄. For the purposes of this paper, used to ontrol re ursive inlining:
we fo us on illustrating how three kinds of omputation an
be a hieved using MetaML: e 2 EMa ro ::= x j x:e j e e
j letre f x1 x2 x3 = e1 in e2
Evaluation Under Lambda: Consider the term xy:(z:z ) x j letma f (~x0 ; x1 ; x2 :x3 ) = e1 in e2
and let us say that we are interested in eliminating the inner j f (e1 ; e2 ; x:e) j hei j ~e
appli ation. In both CBV and CBN, evaluation only works
on losed terms, and therefore, never \goes under lambda." For larity, all ma ros in Core Ma roML have exa tly three
With MetaML it is possible to for e the inner omputation parameters representative of the three kinds of possible pa-
by rewriting the expression as run hxy:~((z:z ) hxi)i, and rameters in Ma roML. Restri ting ourselves to ma ros with
then evaluating it. The result is the desired term: xy:x. exa tly three parameters allows us to avoid substantial ad-
We use su h a pattern of run, bra kets, and es ape in our ministrative detail in Core Ma roML. The three kinds of
interpretation of the ma ro language to ensure that ompu- ma ro arguments are as follows:
tations are performed in the desired order.
Substitution: Consider the term (x:f x x) (g y ). Can we 1. x0 , as indi ated by the pre eding ~, is an early param-
for e the appli ation to be done rst, produ ing f (g y ) (g y )? eter, whi h an be used during ma ro expansion,
This operation is not expressible in CBV or CBN evaluation
semanti s, but is expressible in MetaML by annotating the 2. x1 is a late parameter, whi h might appear in the out-
term as follows: run ((x:hf ~x ~xi) hg y i). put of the expansion, and
3. x2 :x3 de nes a binder/bindee pair of parameters. The
Renaming: While it may be obvious to experts, it seems two variables x2 and x3 are bound variables in the
not widely known that simply using the standard notion s ope of the ma ro de nition but they an only be used
of substitution in de ning the semanti s of a language like in rather spe ial ways enfor ed by the type system.
MetaML is suÆ ient for providing the orre t treatment of The variable x2 must be bound again using a regular
free and bound variables everywhere. In MetaML, there is binding onstru t before x3 an be used. The variable
never any a idental variable apture, and there is never any x3 an only be used in the s ope of x2 . A legal use of
need to express any freshness onditions or to use a gensym- su h a binder/bindee pair is:
like operation. Our semanti s for Ma roML is simple, be-
ause we build on the fa t that using the standard notion letma f ( ; ; x:y ) = a:x:a + x + y in : : :
of substitution in the MetaML semanti s really means that
everything is taken are of. The x in the ma ro de laration binds the two o ur-
ren es of x in the ma ro de nition! All three o ur-
ren es of x ould be renamed to z without hanging the
meaning. The semanti s would, however, be hanged
4. CORE MACROML if we only hange the inner term to z:a + z + y ,
x : tm 2 x:t2 x2 : [x1 : t1 ℄t2 2  and x1 : t11 2
; ; ; `m x : t ; ; ; `1 x : t ; ; ; `1 x2 : t2
; ; ; ; x : tm 1 ` m e : t2 ; ; ; `m e1 : t2 ! t ; ; ; `m e2 : t2
; ; ; ` x:e : t1 ! t2 ; ; ; `m e1 e2 : t
; ; ; ; f : (t1 ! t2 ! t3 ! t)m ; x1 : tm 1 ; x2 : tm
2 ; x3 : t m
3 `m e1 : t
; ; ; ; f : (t1 ! t2 ! t3 ! t)m `m e2 : t4
; ; ; `m letre f x1 x2 x3 = e1 in e2 : t4
; f : (t1 ; t2 ; [t3 ℄t4 ) ) t5 ; ; x2 : [x : t3 ℄t4 ; ; x1 : t2 ; ; x0 : t01 `1 e1 : t5
; f : (t1 ; t2 ; [t3 ℄t4 ) ) t5 ; ; ; `1 e2 : t
; ; ; `1 letma f (~x0 ; x1 ; x:x2 ) = e1 in e2 : t
f : (t1 ; t2 ; [t3 ℄t4 ) ) t5 2 
; ; ; `0 e1 : t1
; ; ; `1 e2 : t2
; ; ; x : t3 ; `1 e3 : t4 ; ; ; `1 e : t ; ; ; `0 e : hti
; ; ; ` f (e1 ; e2 ; x:e3 ) : t5 0
; ; ; ` hei : hti ; ; ; `1 ~e : t

Figure 3: Ma roML Type System

be ause we would be returning a result that ould binder/bindee pair is a pair of a \bound" variable de-
have an unbound variable (that was bound to x) in lared to be of type t3 and an expression of type t4 ,
a subterm (that was bound to y ). The binder/bindee whi h ould ontain a free o urren e of the \bound"
parameter illustrates how de ning new binding on- variable. This notation is inspired by types in FreshML
stru ts works in Ma roML. For Core Ma roML we [34℄.
have pi ked the simplest binding onstru t in the lan-
guage, namely lambda abstra tion x:e. The other  the bindee parameter environment. It arries bindings
binding onstru ts follow naturally. of the form [x : t1 ℄t2 . This environment is needed
for type- he king the body of a ma ro that uses a
binder/bindee parameter of the form x:x1 , so that
The appli ation of a ma ro f (e1 ; e2 ; x:e) also takes exa tly we know that we an only use x1 at type t2 in a on-
three arguments: the rst is an early argument, the se - text where x is bound (with type t1 ).
ond is a late argument, and the third is a binder/bindee
argument. The binder/bindee argument explains the ore  the late parameter environment. It arries bindings
of our treatment of new binding onstru ts: it must be lear of the form t. This environment is needed for type-
what variables are free in what sub-expressions, and both he king the body of a ma ro that uses a late param-
must always be passed together. Note that a binder/bindee eter.
argument must have the right form for the binding stru - the regular environment. Be ause we are in a two-stage
ture (in this ase, lambda). For example, the appli ation setting, it arries bindings of the form tm .
f ((); (); z:z + a) of the ma ro de ned above expands to
a0 :x:a0 + x + (x + a): The rules of the Ma roML type system are presented in
Figure 3. The rst three rules deal with variable lookup.
4.1 Typing Core MacroML The rst rule is the variable (proje tion) rule from MetaML.
The types of Ma roML are the same as MetaML: The next rule is similar, although it re e ts the fa t that late
ma ro parameters an only be used at level one. The third
t 2 TMa ro ::= nat j t ! t j hti rule is similar but it he ks that the bindee variable is used in
The type system, however, is more involved. Typing judg- a ontext where its binder variable has already been bound.
ments have the form ; ; ; `m e : t where m is the level
of a term. We restri t the levels here to 0 (representing early The next three rules are standard for a multi-level language.
omputations) and 1 (representing late omputations). The All the usual rules of SML would be lifted in the same man-
environments have the following roles (and de nitions): ner (although some are is required with e e ts. See Se -
tion 7.)
 the ma ro environment. It keeps tra k of the vari- The next four rules are spe i to ma ros. The rst rule
ous ma ros that have been de lared. These bindings is for a ma ro de nition. Be ause we allow ma ro de ni-
are of the form (t1 ; t2 ; [t3 ℄t4 ) ) t5 . In this binding, tions to be re ursive, the body of the ma ro de laration is
the tuple provides information about the three stan- he ked under the assumption that the ma ro being de ned
dardized parameters. Note that we write [t3 ℄t4 to de- is already de lared. We also add the appropriate assump-
s ribe the binder/bindee argument. Intuitively, the tions about the binder/bindee parameters, the late param-
eter, and the early parameter to the appropriate environ- is, in fa t, that variables are never passed around! Dur-
ments. The rest of the rule is standard. Ma ro appli ation ing ma ro-expansion time, the binder/bindee parameter is
is also analogous to appli ation, although one should note passed in what an be onsidered its HOAS representation.
that e1 and e2 are he ked at di erent levels. The rules for The type of a binder/bindee parameter is also translated
bra kets and es ape are spe ial ases of the same rules in to a fun tion type. Naturally, this is onsistent with the
MetaML. external type of this parameter. The type of a late param-
eter is simply a \delayed" or ode version of the Ma roML
4.2 The Semantics of Core MacroML type of that parameter. No translation is shown for regu-
In this se tion, we present the de nition of the semanti s lar environments, as the translation is simply the identity
of Core Ma roML via an interpretation into MetaML. For embedding.
any well-typed Core MetaML program [℄; [℄; [℄; [℄ `1 e : t the
interpretation [ [℄; [℄; [℄; [℄ `1 e : t℄ will de ne a MetaML term The translation on judgments pro eeds as follows. Terms
( all it e00 ). To get the nal result of running the Ma roML that do not involve ma ros are translated homomorphi ally.
program, we simply evaluate the MetaML term run he00 i. To Late parameters are translated by putting an es ape around
get a more ne-grained view of the evaluation of e00 , we an them. The intuition here is that late parameters only o ur
view it as pro eeding into two distin t steps: inside the de nition of a ma ro, and when they o ur, they
are supposed to be \spli ed into" the ontext where there
are used in order to appear in the output of ma ro expansion
 Ma ro expansion: the Ma roML program e expands as expe ted.
to a MetaML program e01 if:
0 The key rule in the translations is the one for the bindee
he00 i ,! e01 parameters: when a bindee parameter x2 is used in the
where e00 is the interpretation of the Ma roML program body of a ma ro de nition, its translation orresponds to
into MetaML des ribed above (and de ned below). an appli ation of x2 to a pie e of ode arrying the orre-
sponding binder parameter x1 ! All of this is es aped so that
 Regular exe ution: The expansion e01 of e then evalu- the appli ation is performed at ma ro expansion time. To
ates to the answer e02 if: understand what is going on here, keep in mind the trans-
0 lation of the environment , and note that it introdu es an
run e01 ,! e02 arrow type \out of nowhere" during the translation. Thus,
in the target of the interpretation, x2 has an arrow type.
Note that the only new part in the above semanti s is the This is be ause, as we said earlier, the translation produ es
translation from Ma roML to MetaML. The two stages of ode that is passing around a HOAS representation of the
MetaML evaluation are then just standard MetaML rebuild- binder/bindee pair.
ing and evaluation, respe tively. Whenever the original term
does not have any ode types in its Ma roML type, the latter Ma ro de larations are translated to es aped fun tion de -
step would oin ide with standard ML evaluation. larations, i.e., fun tion de larations that are to be exe uted
during expansion. Note however that the body of the fun -
Figure 4 presents the translation, rst de ned on environ- tion being de ned and the ontext where it is used are both
ments, and then de ned on judgments. Although the trans- in bra kets. This is be ause we want to treat both as ode,
lation an be made to map untyped terms to untyped terms, ex ept in pla es where the translation has added other es-
it is ontext-sensitive, and it is therefore easier to de ne it apes.
on judgments of well-typed Core Ma roML programs. To
avoid the risk of potentially onfusing notation, the trans- A ma ro appli ation is translated into an es aped appli a-
lation maps judgments to terms (rather than judgments to tion, for similar reasons. Note that the rst (early) argu-
judgments), as the full MetaML judgments are easy to re- ment to the appli ation is not bra keted, but the se ond
onstru t. (late) argument is. As hinted earlier by the translation of
the types, the binder/bindee argument is translated into a
Empty environments are mapped to empty environments. fun tion whose body is itself a pie e of ode. Intuitively,
The binding for a ma ro is translated into a MetaML type making the body a pie e of ode delays its evaluation. It
that, in essen e, re e ts the semanti s of the spe ial notation is worth noting that the HOAS entities only exist during
we have used; the (level 0) MetaML type: the rst stage (ma ro expansion), and not during the exe-
ution of the program proper. The translation of bra kets
t1 ! ht2 i ! (ht3 i ! ht4 i) ! ht5 i and es ape is straightforward.
orresponds to a fun tion that takes three ( urried) pa- We illustrate the translation on the example at the begin-
rameters. The rst parameter is a \true" value of type ning of the se tion, with a bound in to the type nat1 :
t1 orresponding to the early parameter. The se ond pa-
rameter, however, is a \delayed" or ode value of type t2
orresponding to the late parameter. The third parame-
ter (the binder/bindee parameter) is in fa t translated to [ [℄;[℄; [℄; a : nat1 `1
a fun tion. It is at this point that we an start to ex- letma f ( ; ; x:y ) = a:x:a + x + y
plain how the interpretation of the binder/bindee parame- in f ((); (); z:z + a)℄℄ =
ters works. Re all that in the examples se tion we promised ~(letre f y = ha:x:a + x + ~(y hxi)i
to explain how \variables are passed around." The answer in h~(f () () (z:h~z + ai))i)

[ ;℄ = ;
[ ; f : (t1 ; t2 ; [t3 ℄t4 ) ) t5 ℄ = [ ℄℄; f : (t1 ! ht2 i ! (ht3 i ! ht4 i) ! ht5 i)0
[ ; x2 : [x1 : t1 ℄t2 ℄ = [ ℄℄; x2 : (ht1 i ! ht2 i)0
[ ; x : t ℄ = [ ℄℄; x : hti0
Lambda Terms
x : tm 2 [ ; ; ; ; x : tm 1 `m e : t2 ℄ = e0
[ ; ; ; ` x : t℄ = x m
[ ; ; ; ` x:e : t1 ! t2 ℄ = x:e0
[ ; ; ; `m e1 : t2 ! t℄ = e01 [ ; ; ; `m e2 : t2 ℄ = e02
[ ; ; ; `m e1 e2 : t℄ = e01 e02
[ ; ; ; ; f : (t1 ! t2 ! t3 ! t)m ; x1 : tm1 ; x2 : t m
2 ; x3 : tm
3 `m e1 : t℄ = e01
[ ; ; ; ; f : (t1 ! t2 ! t3 ! t)m `m e2 : t4 ℄ = e02
[ ; ; ; `m letre f x1 x2 x3 = e1 in e2 : t4 ℄ = letre f x1 x2 x3 = e01 in e02
Ma ros
x:t2 x2 : [x1 : t1 ℄t2 2  and x1 : t11 2
[ ; ; ; `1 x : t℄ = ~x [ ; ; ; `1 x2 : t2 ℄ = ~(x2 hx1 i)
[ ; f : (t1 ; t2 ; [t3 ℄t4 ) ) t5 ; ; x2 : [x : t3 ℄t4 ; ; x1 : t2 ; ; x0 : t01 `1 e1 : t5 ℄ = e01
[ ; f : (t1 ; t2 ; [t3 ℄t4 ) ) t5 ; ; ; `1 e2 : t℄ = e02
[ ; ; ; `1 letma f (~x0 ; x1 ; x:x2 ) = e1 in e2 : t℄ = ~(letre f x0 x1 x2 = he01 i in he02 i)
[ ; ; ; `0 e1 : t1 ℄ = e01
[ ; ; ; `1 e2 : t2 ℄ = e02
[ ; ; ; x : t3 ; `1 e3 : t4 ℄ = e03
f : (t1 ; t2 ; [t3 ℄t4 ) ) t5 2 
[ ; ; ; `1 f (e1 ; e2 ; x:e3 ) : t5 ℄ = ~(f e01 he02 i x:he03 i)
Code Obje ts
[ ; ; ; `1 e : t℄ = e0 [ ; ; ; `0 e : hti℄ = e0
[ ; ; ; `0 hei : hti℄ = he0 i [ ; ; ; `1 ~e : t℄ = ~e0

Figure 4: Translating Ma roML to MetaML

As we said at the start of this se tion, the output of the 4.3 Type Safety
translation is wrapped in the ontext run h: : :i and then As mentioned in the introdu tion, de ning the semanti s of
evaluated in MetaML to produ e the result of ma ro ex- Core Ma roML by interpretation into MetaML makes prov-
pansion. Be ause big-step semanti s derivations are hard to ing type safety fairly dire t. In what follows, we state and
draw (and maybe to read), we an \animate" the ompu- outline the proof of this result.
tation using the following sequen e of sound MetaML left-
redu tions [38℄.
Theorem 4.1 (Type Safety). If [℄; [℄; [℄; [℄ `m e : t is
a valid Ma roML judgment, then translating it to MetaML
run h~(letre f y = ha:x:a + x + ~(y hxi)i yields a well-typed MetaML program, and exe uting that pro-
in h~(f () () (z:h~z + ai))i)i gram does not generate any MetaML runtime errors.
! ( all f , rename a when doing substitution)
run h~h~ha0 :x:a0 + x + ~((z:h~z + ai) hxi)iii
! ( an el es ape with bra kets) Proof. The rst part is by Lemma 4.2, and the se ond
run ha0 :x:a0 + x + ~((z:h~z + ai) hxi)i part follows from the type safety property of the MetaML
! ( all inner ) type system presented in previous work [40, 26℄.
run ha0 :x:a0 + x + ~h~hxi + aii
! ( an el es ape with bra kets)
run ha0 :x:a0 + x + (x + a)i In the statement of the theorem, MetaML runtime errors in-
! (run) lude both errors that might o ur at ma ro expansion and
a0 :x:a0 + x + (x + a) run-time errors (de ned pre isely in [40, 26, 38℄). The ne -
essary auxiliary lemma states that our translation preserves
whi h is the expe ted result of ma ro expansion.
Lemma 4.2 (Type Preservation). If ; ; ; `m Re ursive Bindings: A simple but still important issue is
e : t is a valid Ma roML judgment, then [ ℄℄; [ ℄℄; [ ℄℄; `m how re ursive binding onstru ts should be treated. In par-
[ ; ; ; `m e : t℄ : t is a valid MetaML judgment. ti ular, when a ma ro is de ning a new binding onstru t
in terms of an existing re ursive binding onstru t, this in-
Proof. Routine indu tion on the height of the derivation formation should be maintained in the type of the ma ro.
of ; ; ; `m e : t.
Consider the following de laration:

5. PRACTICAL EXTENSIONS OF CORE let ma (let fin x{i} _ = e1{i} in e2 end)

Core Ma roML handles simple fun tional inlining, re ur- = (let fun x{i} _ = e1{i} in e2 end)
sive inlining, and the de nition of simple binding onstru ts. in ... end
By design, Core Ma roML is a minimalisti language whose
purpose is to demonstrate how the main semanti subtleties
of a typed ma ro system an be addressed. We have im- This de laration may appear ambiguous be ause we an ei-
plemented Core Ma roML using a toy implementation of ther expand the fun omprehension into a sequen e of fun
MetaML. We have used the implementation to run a ben h- de larations or a sequen e of mutually-re ursive (\anded")
mark of simple programs in Core Ma roML, and the results fun de larations. However, this an be ompletely deter-
have onsistently been as expe ted. In this se tion, we de- mined by how the fin onstru t is used: if it is used as
s ribe extensions of Core Ma roML with additional features a disjoint sequen e, then that is what should be produ ed.
that would be desirable in a pra ti al implementation. We If it is used as an anded sequen e, then the result should
expe t that all these extensions are not hard to implement. be like-wise. In the latter ase, however, we need to he k
that the parameters to the anded sequen es of fins should
Let Bindings: In the introdu tion, we have presented exam- not have dupli ate variables names. All these he ks an be
ples of let-expression ma ros with only one binding. How- done stati ally.
ever, the same ma ro de nition an be used to expand let-
expressions with multiple bindings. For this purpose, we Dist- x Operators: Finally, we ome to an extension that
propose the use of a omprehension-like notation to allow is rather orthogonal to the rest of our proposal. However,
the user to express su h ma ros. For example, the expres- in pra ti al ma ro systems, it is a valuable addition. In
sion: parti ular, it is relatively easy to add dist- x operators to
our language. The key idea is that ea h ma ro de nition
should still be determined by the rst symbol used in its
let ma (let seq x{i} = e1{i} in e2 end) = name. With su h an extension, it is possible to de ne some
$(let val x{i} = (print (Int.toString i); other basi onstru ts in a language:
in ?e2 end)
in let seq y = f $7 let ma {if, then, else} if then t else f =
seq z = h y ase of
in g z end true => t
end | false => f
in if true then 1 else 2 end
would expand to:
The syntax simply extends what we have seen before by
$(let val x1 = (print (Int.toString 1); ?(f $7)) a de laration of keywords that an be used in onjun tion
val x2 = (print (Int.toString 2); ?(h x1)) with the ma ro if. Then, the rest of the argument list
in ?(g x2) end) di tates the \dist- x arity" of this ma ro. The only om-
pli ation with the introdu tion of su h ma ros is that they
where it be omes apparent that i is an impli it omprehen- make parsing ontext sensitive. However, this is already the
sion parameter that gets bound to the index of the binding ase in SML be ause of in x operators.
under onsideration, and that x{i} and e{i}, are the pa-
rameters for this ith -binding. 6. RELATED WORK
Our approa h for deriving the type system for Ma roML was
Note that the number of de larations (the range of i) will be to rst develop the translation in an essentially untyped set-
known at translation time, as it is manifest from the appli- ting, and then to develop a type system that hara terizes
ation of the ma ro. However, be ause vanilla MetaML does when the result of the translation is a well-typed MetaML
not have support for onstru ting de larations of arbitrary program. The earliest instan e of su h a translation ap-
length, the most dire t approa h to interpret this proposal pears in a work by Wand [43℄. Be ause we start with the
would be to produ e one MetaML fun tion for ea h ma ro untyped setting, we expe t that similar derivations are pos-
appli ation. This tri k is similar to polyvariant spe ializa- sible for ri her MetaML type systems (in luding features
tion in partial evaluation [18℄. The obvious disadvantage su h as polymorphism and e e ts, for example).
of this approa h is that it in ates the size of MetaML. We
would like to explore extensions to MetaML that would al- The earliest use of a binary type onstru tor to indi ate the
low us to interpret this new onstru t in a more natural type of a \pie e of ode with a free variable in it" su h as
fashion. our [t1 ℄t2 seems to have been in Miller's proposal for \an
extension of ML to handle bound variables in data stru - that it may be simpler and more appropriate to move di-
tures." Miller's proposal is more ambitious than ours in re tly to a full- edged multi-stage programming language.
that it tries to deal with data types that have some bind- Part of the appeal of ma ro systems, we believe, goes away
ing stru ture, but it neither addresses the issue of de ning when we attempt to push them to the higher-order and re-
new binding onstru ts in a user-level language nor gives a e tive setting. On the other hand, given that we have de-
formal semanti s for the proposed onstru ts. Indeed, work ned ma ros in terms of a multi-stage language, it should
by Pasali , Sheard and Taha suggests that Miller's proposal be possible to merge ma ros and MetaML into the same
may need to be reformed before it an have a simple seman- language without any surprising intera tions.
ti s [32℄. More re ently, FreshML has also used a similar
binary type onstru tor based on a denotational model [34℄. To on lude, while this paper addresses key semanti on-
The Twelf system uses a mixture of dependent types that erns in developing an expressive, type-safe ma ro system,
seems to be, at least intuitively, similar to our [x : t1 ℄t2 on- this is only a start. We have only built a simple prototype
stru tion. To our knowledge, our work seems to be the rst during this work. The prototype involved a dire t implemen-
to investigate the appli ation of su h type systems dire tly tation of MetaML semanti s and a dire t implementation of
to the domain of ma ro systems, and to expose the onne - the translation. In the future, we hope to integrate this work
tions with multi-stage languages and higher-order syntax. with ongoing work on multi-stage extensions of the major
stati ally-typed fun tional languages, namely SML, O aml,
Finally, the title of the paper by Bawden [3℄ suggests that and Haskell.
it is related to the present work, but it does not seem to
address the issue of typing or type systems formally. 8. REFERENCES
[1℄ Ariola, Z. M., and Sabry, A. Corre tness of monadi
7. CONCLUSION state: An imperative all-by-need al ulus. In ACM
Symposium on Prin iples of Programming Languages
We have presented a proposal for a typed ma ro system, and (1998), ACM Press, pp. 62{74.
have shown how it an be given a rigorous yet readable se- [2℄ Barendregt, H. P. The Lambda Cal ulus: Its Syntax and
manti s via an interpretation into the multi-stage program- Semanti s, revised ed., vol. 103 of Studies in Logi and the
ming language MetaML. The interpretation is essentially a Foundations of Mathemati s. North-Holland, Amsterdam,
denotational semanti s where MetaML is the internal lan- 1984.
guage of the model. Su h models have already been studied [3℄ Bawden, A. First- lass ma ros have types. In Pro eedings
elsewhere [4℄. But be ause MetaML enjoys a simple and of the 27th ACM SIGPLAN-SIGACT Symposium on
intuitive operational semanti s, our proposal is easy to im- Prin iples of Programming Languages (POLP-00) (N.Y.,
plement in a dire tly usable form. Jan. 19{21 2000), ACM Press, pp. 133{141.
[4℄ Benaissa, Z. E.-A., Moggi, E., Taha, W., and Sheard,
The ma ro language that we have presented, Ma roML, has T. Logi al modalities and multi-stage programming. In
useful and novel features, ombining both stati typing and Federated Logi Conferen e (FLoC) Satellite Workshop on

allowing the user to de ne new binding onstru ts. In try- Intuitionisti Modal Logi s and Appli ations (IMLA)
ing to a hieve this, we have used ideas from both HOAS
(to implement our proposal in a multi-stage setting) [33℄ [5℄ Cal agno, C., Moggi, E., and Taha, W. Closed types as
and FreshML (to provide the surfa e syntax and ideas in a simple approa h to safe imperative multi-stage
programming. In 27th International Colloquium on
the sour e language) [34℄. It may well be that our language Automata, Languages, and Programming (ICALP)
provides some new insights on the link between the two ap- (Geneva, 2000), vol. 1853 of Le ture Notes in Computer
proa hes to treating binding onstru ts. S ien e, ACM Press, pp. 25{36.

[6℄ Curry, H. B., and Feys, R. Combinatory Logi , Volume

We have argued that ma ros are useful. But the moral of the I. Studies in Logi and the Foundations of Mathemati s.
paper is of a more te hni al nature: multi-stage program- North-Holland, Amsterdam, 1958. Se ond printing 1968.
ming languages are a good foundation for the semanti s- [7℄ Davies, R. A temporal-logi approa h to binding-time
based design of ma ro systems. We have shown how a formal analysis. In 11th Annual IEEE Symposium on Logi in
multi-stage interpretation of ma ro systems provides an el- Computer S ien e (LICS) (New Brunswi k, 1996), IEEE

egant way of avoiding binding issues, de ning new binding Computer So iety Press, pp. 184{195.
onstru ts, and provides a sound basis for developing type [8℄ Davies, R., and Pfenning, F. A modal analysis of staged
systems for ma ro languages. omputation. In 23rd Annual ACM Symposium on
Prin iples of Programming Languages (POPL) (St.

In this paper, we have not onsidered type safety in the pres- Petersburg Bea h, 1996), pp. 258{270.
en e of imperative features (referen es, ex eptions) during [9℄ Dybvig, R. K., Hieb, R., and Bruggeman, C. Synta ti
expansion time. In this setting, we expe t the work on im- abstra tion in S heme. Lisp and Symboli Computation 5,
4 (De . 1992), 295{326.
perative multi-level languages to be of dire t relevan e [42,
5℄. We have also not onsidered a multi-level ma ro sys- [10℄ Erko k, L., and Laun hbury, J. Re ursive monadi
tem primarily for the reason of simpli ity. We would like bindings. In Pro eedings of the Fifth ACM SIGPLAN
to onsider su h an extension in future work. But there International Conferen e on Fun tional Programming,
ICFP'00 (September 2000), ACM Press, pp. 174{185.
are restri tions on the system that may be a bit more hal-
lenging to alleviate. For example, we have not onsidered [11℄ Felleisen, M. On the expressive power of programming
languages. In S ien e of Computer Programming (1991),
higher-order ma ros (ma ros that take other ma ros as pa- vol. 17, pp. 35{75. Preliminary version in: Pro . European
rameters) and we have not onsidered ma ros that generate Symposium on Programming, Le ture Notes in Computer
other ma ros. For su h expressiveness, however, we expe t S ien e, 432. Springer-Verlag (1990), 134{151.
[12℄ Fiore, M., Plotkin, G., and Turi, D. Abstra t syntax Symposium on Prin iples of Programming Languages, San
and variable binding. In Pro eedings of the 14th Annual Antonio, Texas (New York, NY, Jan. 1999), ACM,
Symposium on Logi in Computer S ien e (LICS'99) pp. 43{56.
(Trento, Italy, July 1999), G. Longo, Ed., IEEE Computer [28℄ Nielson, F., and Nielson, H. R. Two-level semanti s and
So iety Press, pp. 193{202. ode generation. Theoreti al Computer S ien e 56, 1
[13℄ Glu k, R., and Jrgensen, J. EÆ ient multi-level (1988), 59{133.
generating extensions for program spe ialization. In [29℄ Okasaki, C. Purely Fun tional Data Stru tures. PhD
Programming Languages: Implementations, Logi s and
thesis, S hool of Computer S ien e, Carnegie Mellon
Programs (PLILP'95) (1995), S. D. Swierstra and University, 1996.
M. Hermenegildo, Eds., vol. 982 of Le ture Notes in
Computer S ien e, Springer-Verlag, pp. 259{278. [30℄ Oliva, D. P., Ramsdell, J. D., and Wand, M. The
 k, R., and Jrgensen, J. Fast binding-time analysis
VLISP veri ed pres heme ompiler. Lisp and Symboli
[14℄ Glu Computation 8, 1/2 (1995), 111{182.
for multi-level spe ialization. In Perspe tives of System
Informati s (1996), D. Bjrner, M. Broy, and I. V. [31℄ Oregon Graduate Institute Te hni al Reports. P.O. Box
Pottosin, Eds., vol. 1181 of Le ture Notes in Computer 91000, Portland, OR 97291-1000,USA. Available online
S ien e, Springer-Verlag, pp. 261{272. from ftp:// h-reports/README.html.
 k, R., and Jrgensen, J. An automati program
Last viewed August 1999.
[15℄ Glu
generator for multi-level spe ialization. LISP and Symboli [32℄ Pasali , E., Sheard, T., and Taha, W. DALI: An
Computation 10, 2 (1997), 113{158. untyped, CBV fun tional language supporting rst-order
datatypes with binders (te hni al development). Te h. Rep.
[16℄ Gomard, C. K., and Jones, N. D. A partial evaluator for CSE-00-007, OGI, 2000. Available from [31℄.
untyped lambda al ulus. Journal of Fun tional
Programming 1, 1 (1991), 21{69. [33℄ Pfenning, F., and Elliott, C. Higher-order abstra t
syntax. In Pro eedings of the Symposium on Language
[17℄ Hofmann, M. Semanti al analysis of higher-order abstra t Design and Implementation (Atlanta, 1988), pp. 199{208.
syntax. In Pro eedings of the 14th Annual Symposium on
Logi in Computer S ien e (LICS'99) (Trento, Italy, July [34℄ Pitts, A. M., and Gabbay, M. J. A metalanguage for
1999), G. Longo, Ed., IEEE Computer So iety Press. programming with bound names modulo renaming. In
Mathemati s of Programme Constru tion (2000), vol. 1837
[18℄ Jones, N. D., Gomard, C. K., and Sestoft, P. Partial of Le ture Notes in Computer S ien e, Springer-Verlag,
Evaluation and Automati Program Generation.
pp. 230{255.
Prenti e-Hall, 1993.
[35℄ Plotkin, G. D. Call-by-name, all-by-value and the
[19℄ Kohlbe ker, E., Friedman, D. P., Felleisen, M., and lambda- al ulus. Theoreti al Computer S ien e 1 (1975),
Duba, B. Hygieni ma ro expansion. In Pro eedings of the 125{159.
ACM Conferen e on LISP and Fun tional Programming
(Cambridge, MA, Aug. 1986), R. P. Gabriel, Ed., ACM [36℄ Sabry, A. What is a purely fun tional language? Journal
Press, pp. 151{181. of Fun tional Programming 8, 1 (Jan. 1998), 1{22.

[20℄ Lewis, J. R., Laun hbury, J., Meijer, E., and Shields, [37℄ Sheard, T. Using MetaML: A staged programming
M. Impli it parameters: Dynami s oping with stati types. language. Le ture Notes in Computer S ien e 1608 (1999),
In Pro eedings of the 27th ACM SIGPLAN-SIGACT 207{??
Symposium on Prin iples of Programming Languages [38℄ Taha, W. Multi-Stage Programming: Its Theory and
(POLP-00) (N.Y., Jan. 19{21 2000), ACM Press, Appli ations. PhD thesis, Oregon Graduate Institute of
pp. 108{118. S ien e and Te hnology, 1999. Available from [31℄.
[21℄ Miller, D. An extension to ML to handle bound variables [39℄ Taha, W. A sound redu tion semanti s for untyped CBN
in data stru tures: Preliminary report. In Informal multi-stage omputation. Or, the theory of MetaML is
Pro eedings of the Logi al Frameworks BRA Workshop non-trivial. In Pro eedings of the Workshop on Partial
(June 1990). Available as UPenn CIS te hni al report Evaluation and Semanti s-Based Program Maniplation
MS-CIS-90-59. (PEPM) (Boston, 2000), ACM Press.
[22℄ Mit hell, J. C. On abstra tion and the expressive power [40℄ Taha, W., Benaissa, Z.-E.-A., and Sheard, T.
of programming languages. In Theoreti al Aspe ts of Multi-stage programming: Axiomatization and type-safety.
Computer Software (1991), T. Ito and A. R. Meyer, Eds., In 25th International Colloquium on Automata, Languages,
vol. 526 of Le ture Notes in Computer S ien e, and Programming (ICALP) (Aalborg, 1998), vol. 1443 of
Springer-Verlag, pp. 290{310. Le ture Notes in Computer S ien e, pp. 918{929.

[23℄ Moggi, E. Notions of omputation and monads. [41℄ Taha, W., and Sheard, T. Multi-stage programming with
Information and Computation 93, 1 (1991). expli it annotations. In Pro eedings of the Symposium on
[24℄ Moggi, E. A ategori al a ount of two-level languages. In Partial Evaluation and Semanti -Based Program

Mathemati s Foundations of Program Semanti s (1997), Manipulation (PEPM) (Amsterdam, 1997), ACM Press,
Elsevier S ien e. pp. 203{217.
[25℄ Moggi, E. Fun tor ategories and two-level languages. In [42℄ Thiemann, P., and Dussart, D. Partial evaluation for
Foundations of Software S ien e and Computation
higher-order languages with state. Available online from
Stru tures (FoSSaCS) (1998), vol. 1378 of Le ture Notes in

Computer S ien e , Springer Verlag. index.html, 1996.

[26℄ Moggi, E., Taha, W., Benaissa, Z. E.-A., and Sheard, [43℄ Wand, M. Embedding type stru ture in semanti s. In
T. An idealized MetaML: Simpler, and more expressive. In Conferen e Re ord of the Prin iples of Programming

European Symposium on Programming (ESOP) (1999),

Languages (1985), pp. 1{6.
vol. 1576 of Le ture Notes in Computer S ien e, [44℄ Wand, M. The theory of fexprs is trivial. Lisp and
Springer-Verlag, pp. 193{207. Symboli Computation 10 (1998), 189{199.

[27℄ Moran, A., and Sands, D. Improvement in a lazy ontext:

An operational theory for all-by-need. In Conferen e
Re ord of POPL 99: The 26th ACM SIGPLAN-SIGACT