<<

From Macros to Reusable Generative

Programming



Shriram Krishnamurthi and Bruce F Duba

Department of Science

Rice University

Houston TX USA



Department of

Seattle University

Seattle WA USA

Abstract Generative programming is widely used b oth to develop new

programming languages and to extend existing ones with domainsp eci

sublanguages This pap er describ es McMicMac a framework for gener

ative programming McMicMac uses treetransforming macros as lan

guage sp ecications and enhances them with inherited and synthesized

attributes The enhanced transformers can describ e general compila

tion tasks Families of these sp ecications are group ed into mixinlike

collections called vo cabularies Programmers can dene new languages

by comp osing these vo cabularies Wehave implemented McMicMac for

Scheme and used it to build several systems including the DrScheme

programming environment The principles of McMicMac carry over to

other languages and environments

Intro duction

Generative programming is an old and go o d ideawrite programs to write your

programs for you This idea has b een applied widely from compilation to creating

domainsp ecic languages to the masspro duction of comp onents It is gaining

increasing prominence due to its p otential economic impact b ecause it can b oth

reduce manual lab or and increase the eciency and correctness of programs

In this pap er we describ e a general framework for generative programming

in Scheme Concretelywe describ e McMicMac a framework develop ed at

Rice University McMicMac supp orts the pro duction of extensible language com

p onents A programmer can generate new languages by comp osing language

comp onents Because the comp onents are parameterized over the base language

McMicMac programmers can reuse the same languagedening comp onents to

build many dierent languages The system thus greatly simplies the design and

implementation of domainsp ecic languages as extensions of base languages

Our system plays a crucial role in the construction of a large programming

environment DrScheme Conversely the pro cess of building DrScheme has

This work is partially supp orted by NSF grants CCR CDA and

CCR and a Texas ATP grant

help ed us debug and rene the design of our system McMicMac has also b een

used to build to ols for languages other than Scheme Starting with a typ echecker

and for a parenthetical version of Java it has b een used to create lan

guage extensions representing design patterns and other sp ecications

The rest of this pap er is organized as follows Section providesanex

tended example that illustrates some of the kinds of abstractions that genera

tive programming makes p ossible Section describ es the structure of McMicMac

through a series of examples and section renes this discussion Section sum

marizes the deploymentofMcMicMac Section discusses related eorts and

section oers concluding remarks and suggests directions for future work

An Illustrative Example

Supp ose a programmer wanted to distribute a library that creates and executes

nitestate automata The library of typ es and pro cedures or classes with meth

o ds should hide the actual representation used for the automata b ecause there

areatleasttwo dierent automata representations data structures and exe

cutable values Data structures are useful for manipulating automata as data

eg for minimizing automata They can also b e run via an though

this can b e inecient If the automata are b eing created solely for execution

then it is typically much more ecient to translate them directly into co de such

as functions or lab eled statements

Hence the library should oer programmers a way to sp ecify inline automata

in a representationindep endent yet intuitive manner This would allow clients

to write expressions suchasthatshown in gure The example uses a new

construct automaton to dene an automaton that starting in state checks

whether a stream of s and s b egins with and then alternates strictly b etween

the twovalues

The sp ecication in gure might translate into the Scheme co de shown in

gure It represents automata as pro cedures that consume an input stream

The states are nested mutuallyrecursive pro cedures Each pro cedure represents

one states transition relation All unexp ected inputs generate an exception

unexpectedinputexn so the empty transition relation represents an error state

If the automaton attempts to insp ect past the end of a nite input stream

a dierent exception is raised which a client can handle to observe successful

completion Because programming languages likeScheme optimize calls in tail

p osition to jumps or gotos the state transitions in the example are quickand

accumulate no evaluation context collo quiallystack space

Unfortunately the library programmer cannot dene automaton b ecause it

is not a pro cedure The subterms of automaton are not expressions in Scheme

as pro cedure arguments must b e rather they are terms in a distinct domain

sp ecic language Furthermore automaton is a binding construct as claried

by gure which cannot b e dened pro cedurally Therefore automaton can not b e dened in most traditional programming languages

automaton state

state  errorstate

 state

state  state

 errorstate

errorstate

Fig An Automaton Description

lambda inputstream

letrec

state lambda

case nexttoken inputstream

errorstate

state

else raise ob ject unexpectedinputexn

state lambda

case nexttoken inputstream

state

errorstate

else raise makeob ject unexpectedinputexn

errorstate lambda

case nexttoken inputstream

else raise makeob ject unexpectedinputexn

state

Fig Compiled Automaton Representation

The automaton library mightcontain other op erations of this form For in

stance the library mayprovide a means for interleaving the execution of two

automata This would enable the client programmer to write

runalternating M stream M stream

which runs automaton M on stream stream and M on stream in strict

alternation In this case even though b oth subterms of runalternating are

legal Scheme expressions Schemes callbyvalue evaluation order would rst run

M on stream until terminationwhichmaynever o ccurb efore it b egins to

run M Thus runalternating also cannot b e a pro cedure in a callbyvalue

language

Both constructs illustrate useful and imp ortant abstractions that help pro

grammers write software eectively These abstractions are not proceduralhow

ever Instead they dene notations that are not part of the languages syntax

In other cases they require b ehavior that is dierent from what the languages

semantics sp ecies More generally automaton and runalternating are b oth

linguistic abstractions ie they create a little language within a larger language

denemacro automaton 

automaton startstate

statename input  newstate

 syntax

lambda inputstream

letrec statename

lambda

case removetoken inputstream

inputnewstate

else raise makeob ject unexpectedinputexn

startstate

Fig Automaton Macro

to accomplish some sp ecialized task Generative programming frameworks must

supp ort such language construction

The McMicMac Framework

McMicMac is a framework for creating languages such as that for automata

We explain McMicMac through a series of examples reecting increasingly com

plex proto cols The examples are intentionally simplistic in avor but they cor

resp ond to some of the nontrivial uses wehave encountered while building

DrScheme

Macros

Examples like automaton and runalternating are expressible as McMic

Mac macros The macros of McMicMac are descendants of those in Lisp and

Scheme They transform treeshap ed data rather than manipulating

at data like the stringpro cessing macros in the C prepro cessor In short

macros implement a simple form of extensible parsing

A parser is conceptually a table of rules that map syntactic shap es to co de

When the input matches a shap e called a trigger the parser lo oks up the trig

gers transformation rule called the elaborator and uses it to pro duce abstract

syntax The parsing table is traditionally xed thus limiting the input language

a parser can recognize Macro denitions add rules to a parsers table Unlike

traditional parse rules though macro rules do not directly generate abstract

syntax Instead they generate terms in the source language The parser then

reanalyzes the generated term and continues this pro cess until it obtains a

canonical form

In McMicMac the programmer denes triggers using a patternmatching no

tation originally due to Kohlb ecker and Wand When an input term matches

denemacro automaton 

automaton startstate

statename input  newstate

 syntax

makeautomatonrep startstate

list makestaterep statename

maketransitionrep input newstate

Fig Alternate Automaton Macro

a trigger the matcher generates a pattern environment that maps pattern vari

ables to the corresp onding source terms in the input It then invokes the elab o

rator to generate a source term This term can b e parameterized over subterms

in the input The elab orator extracts these input subterms from the pattern

environment

Figure presents a concrete example the macro for the automaton con

struct of section The keyword denemacro is followed by a set of literals

here automaton and  that may app ear in the input The literals are fol

lowed by the trigger All symb ols in the trigger that do not app ear in the literal

set are pattern variables A pattern followed by ellipses matches zero or

more instances of the pattern It binds each pattern variable to the sequence

of subterms that corresp ond to the pattern variables p osition in the matching

instances Ellipses can b e nested arbitrarily deep

The macro denition sp ecies an elab orator following the  keyword The

elab orator uses syntax to construct a new source term The syntax form con

sumes a template and converts the template into a term in the source language

by replacing all pattern variables with their bindings from the implicit pattern

environment Thus in the output term startstate statename input and new

state are replaced with the corresp onding source text in the input expression

while all other names are inserted literally

Macros of this sort have traditionally b een put to four main uses

to create new binding constructs The pro cedural translation of automaton

turns the statenames into binding and b ound o ccurrences of variables

to mask the creation of a datastructure Figure shows an alternate imple

mentation of automaton that represents automata as data structures

to represent structural program prop erties such as uses of design patterns

to aect the order of evaluation For instance runalternating requires

delayed evaluation in a callbyvalue language The macro can wrap the

expressions in pro cedures that are invoked to control stepping

Wehave elided from our sp ecication many McMicMac features that are useful in practice eg the macro writer can sp ecify guards on the structure of subterms

denemicro if for if s

if test then else  lambda

makeifir

dispatch syntax test

dispatch syntax then

dispatch syntax else

Fig A Micro Sp ecication

As the automaton example illustrates a single macro can serveseveral of

these purp oses simultaneously This is esp ecially likely to happ en in the case of

data languages whose constructs are supp osed to mask their representation of

the data from the client programmer since the same source can b e used to gener

ate either representation Figure presents an alternate compiled representation

for automata instead of creating pro cedures it generates a data structure

Dierent applications can cho ose alternate expansions using the mechanism

describ ed in section without anyintervention from the user who sp ecies

the automata Linguistic extensions are esp ecially imp ortant in this context

b ecause they are often the only way to mask these concrete representations In

most languages for instance it is imp ossible to dene a construct that elab orates

into a pro cedure This makes it extremely dicult if not imp ossible to write

the automaton abstraction through any other means

Beyond Conventional Macros

Though conventional macros can describ e manyinteresting linguistic abstrac

tions they are not p owerful enough for many other generativeprogramming

tasks McMicMac therefore generalizes macros in several ways These general

ized macros propagate information ab out the program to guide elab oration

From Expansion to Parsing Parsers have the typ e scheme

sour ce  ir

where sour ce is the typ e of source expressions and ir that of the intermediate

representation In many cases McMicMac programmers writing language exten

sions need the p ower to generate terms of typ e ir directly McMicMac thus allows

programmers to create such elab orators called micros

In principle micros havethetyp e

sour ce  ir

in contrast to macros which denote sourcetosource rewriting functions

sour ce  sour ce

denemicro if for if s

if test then else  lambda env

makeifir

dispatch syntax test env

dispatch syntax then env

dispatch syntax else env

denemicro lambda for lambdas

lambda vars body  lambda env

makelambdair vars

dispatch syntax body append vars env

Fig Micros with Attributes

In practice the parsing pro cess describ ed in section has two parts the elab o

rators that create ir and the dispatcher that do es pattern matching and invokes

an elab orator The dispatcher called dispatch has typ e

sour ce  micr o

ie given a source term it returns the corresp onding micro Micros are elab o

rators represented as pro cedures of no arguments that create ir whose typ e we

denote as

 ir

The reason for this seemingly needless level of indirection will b ecome clear

in the following sections The output of micros unlike that of macros is not

automatically expanded again If it were automatically expanded this could

result in a typ e conict Therefore a micro must invoke dispatch to reduce

source terms to ir

Figure shows the micro denition for a simple conditional construct Like

denemacro denemicro is followed by a list of literals and a trigger pat

tern To the rightofthe keyword is the sp ecication of the micros elab orator

a pro cedure of no arguments The elab orator uses makeifir to construct the ir

representation of if expressions The invo cation

dispatch syntax test

extracts the source term corresp onding to test from the pattern environment

uses dispatch to obtain the corresp onding micro which is a pro cedure of no

arguments and invokes the micro to generate the ir value for test

Attributes Supp ose a programmer wants a simple value insp ection facility

Sp ecically the expression dump should print the names and values of all

the variables b ound in the lexical scop e Provided wehave access to the names

of all the variables in that lexical context the transformation asso ciated with

dump is quite straightforward McMicMac allows programmers to makethis

contextual information explicit by asso ciating attributes with the dispatcher

Thus a programmer can declare the typ e of a micro to b e

env  ir

where env is the typ e of the lexical environment The micro can insp ect this

environment to determine the names of the b ound variables

This typ e generalizes to

attr   ir

to indicate that there can b e several attributes Every micro must accept all the

attributes and must propagate them to micro dispatches on subterms Figure

presents the denition for lambda which aects the set of lexical variables

listed in env and a revised denition of if which do esnt

To use McMicMac an application must invoke dispatch on the source pro

gram while supplying appropriate values for all the attributes The result of

invoking dispatch is an ir value which the program can use for subsequent

pro cessing Some applications use the same typ e for the source and ir ie they

only exploit attributes not the ability to transform representations

Threaded Attributes One p ossible ir to cho ose may b e the set of values

in the language In that case the parser mayconvert programs to their

nal answers ie it may really b e an interpreter We exp ect McMicMac to deal

with such transformations to o They are useful for prototyping small embedded

domainsp ecic languages or for optimizing co degenerators Attributes can rep

resentvarious asp ects of the languages evaluation In gure for example the

environmentmaintains only a list of names b ound in each context but in an

interpreter the environment could map names to lo cations or values

Nontrivial languages though havetwo kinds of attributes Some attributes

eg environments are functional meaning they do not represent computational

eects Other attributes however are threaded They are aected in the pro

cessing of subterms and their order of propagation from the pro cessing of one

subterm to another matters A canonical example of such an attribute is the

store If the same store were passed to all subterms then sideeects in the

evaluation of one would not b e visible in the other Micros therefore return the

up dated values of threaded attributes along with the irThus the typeofa

micro in the interpreter implementation can b e

env  stor e  ir  stor e

or in general micros can haveatyp e with the shap e

f unattr   thr eadattr   ir  thr eadattr 

Once again it is the micro programmers resp onsibilitytoinvoke McMicMac

provide arguments for the attributes accept the nal ir value and the values of the threaded attributes and pro cess them

denemicro set for sets

set var val  lambda env store

letvalues valvalue valstore

dispatch val env store

values the value

voidvalue

the new store

extend store var valvalue

denemicro for function applicatio nsn o literals

fun arg  lambda env store

letvalues funvalue funstore

dispatch fun env store

letvalues argvalue argstore

dispatch arg env funstore

functions must return valuestore pairs

funvalue argvalue argstore

Fig Threaded Attributes

We illustrate this new form of micro with two denitions in gure that im

plement a stateful language in a purely functional manner using the storepassing

style technique from denotational semantics set is Schemes assignment state

ment The co de uses Schemes multiplevalue facility to return the actual value

and the p otentially mo died store

Mo dular Sp ecications

Wehavethusfar discussed the kinds of transformations that programmers can

express In this section we discuss how programmers can group these transfor

mations into reusable units

Vo cabularies Most programming languages consist of several sublanguages

those of expressions statements typ es argument lists data and so on The pro

grammer must therefore sp ecify which sublanguage a micro extends McMicMac

provides vocabularies for this purp ose A vo cabulary is a grouping of related mi

cros All micros in a vo cabulary must satisfy the same typ e signature Figure

illustrates the revised declarations from earlier examples Each micro declares

memb ership in a vo cabulary just b efore sp ecifying its literal set

The sum of declarations in a vo cabulary sp ecies the syntax and the elab

oration rules of a language Put dierentlyavo cabulary describ es the syntax

table that is used by dispatchandmust therefore b e a parameter to dispatch

Weupdatethetyp e of dispatch from section to reect this

sour ce  v ocab  micr o

dene schemeexprs dene automata

makevo cabulary makevo cabulary

denemicro schemeexprs set denemicro automata

set var val  automaton 

lambda thisvocab env store automaton 

 lambda thisvocab 

denemicro schemeexprs denemicro automata

fun arg  runalternating

lambda thisvocab env store runalternating 

 lambda thisvocab 

Fig Vo cabulary Sp ecications

dene compiler makevo cabulary dene analysis

denemicro compiler let makevo cabulary

let var val body  denemicro analysis let 

 denemicro analysis letrec 

denemicro compiler letrec

letrec var val body 

dene analysislanguage



extendvocabulary schemeexprs

analysis

dene compilerlanguage

extendvocabulary schemeexprs

compiler

Fig To olDep endent Expansions

The change in the typ e of dispatch forces us to up date the programming

pattern for micros Each recursive call to dispatch must pass along a vo cabulary

which the invoked micro must accept

As we describ e b elow however a micro may not always knowwhichvocabu

lary it is in Micros therefore takethevo cabulary from which they were selected

as an argumentin gure each micro accepts a vo cabulary thisvocab asits

rst argumentwhich they use to pro cess subterms in the same language alter

natively they can cho ose a dierentvo cabulary for subterms in other languages

For instance a function declaration mayhave some subterms in the expression

language and others in the language of typ es Micros therefore havethetyp e

scheme

vocab  f unattr  thr eadattr   ir  thr eadattr 

Comp osing Vo cabularies McMicMac actually allows programmers to build

vo cabularies by extending and comp osing them Thus programmers can divide

a language into sets of related features and comp ose these features to build a

pro cessor for the complete language A programmer can also create an extension

vo cabulary that overrides some denitions in a base vo cabulary with to olsp ecic

constraints This explains why a micro may not knowwhichvo cabulary it is in

after all the nonoverridden micros of the base are also in the new comp osite

vo cabulary This scenario is analogous to instance variables in an ob jectoriented

language that reside b oth in a class and in its extensions

With vo cabularies we can generate programs in various interesting ways

While traditional transformation techniques are limited in where they can

b e appliedmacros and templates are usually restricted to the expression or

statement languagesthe McMicMac programmer can write transformations

for any sublanguage For instance wehave used it to dene abbreviations

over typ es and to extend the language of pro cedural parameters

In realistic programming environments dierent programpro cessing to ols

often have diering views of the underlying language For example a com

piler might translate the binding construct let which creates nonrecursive

lo cal bindings into a lo cal function application while treating letrec which

intro duces mutuallyreferential lo cal bindings as a primitive In contrast a

p olymorphic typ e inference engine might treat let as a core form while it

will transform letrec into a more primitive term These distinctions are easy

to express through vo cabularies as shown in gure The function extend

vocabulary extends the language of its rst argument with the triggers and

elab orators of the second overriding clashes in favor of the second

Some languages allow programmers to write lexicallyscop ed macros

This is easy to dene in McMicMac The micro for a lexical macro construct

creates a temp orary vo cabulary p opulates it with the lo cal macro and ex

tends the current language with the new macro Because these are lo cal not

global changes the language extension disapp ears when the b o dy has b een

parsed so terms outside this lexical context are unaected

A programmer can use vo cabularies to organize several traversals over the

program Typically earlier passes synthesize information for later passes For

example a programmer maywant to add rstclass closures to an ob ject

oriented language likeJava The translator that implements this trans

formation would need to determine the free variables of the closures

b o dy to create a class to represent the closure and move its denition to

the toplevel as required in many languages and to rewrite the creation

and uses of the closure

A series of vo cabularies solves this problem elegantly The rst maintains the

lexical environment while traversing co de gure when it encounters an

instance of the closure construct it traverses the b o dy with a vo cabulary that

computes the set of free variables This list of free variables is the ir of this

vo cabulary It can then generate the class denition A threaded attribute

accumulates toplevel denitions created in internal contexts and propagates

them outward Finally another vo cabulary rewrites the creation and use

expressions Determining uses can b e done either from typ e information or

through a dynamic check dep ending on the target language

If a larger language is constructed by comp osing smaller language layers

programmers can dene restricted versions of the larger language by leaving

out some layers Wehave found this ability esp ecially useful in the DrScheme

programming environment which presents the Scheme programming

language as a sequence of increasingly complex sublanguages This hides

the complexity of the complete language from the student in particular it

ags terms that are errors in the linguistic subset but that might b e legal

though often not what the student exp ectedin the full language This

provides much b etter feedbackthananenvironment for just the complete

language would provide and considerably improves the learning exp erience

ExtensibilityandValidation

To implement a system like McMicMac in other languages programmers must

resolve the tension b etween extensibilityandvalidation

Extensibility There are two main sources of extensibilityinMcMicMacboth

related to vo cabularies

Vo cabularies resemble classes with inheritance since they havevariable

parentvo cabularies they are essentially mixins which enhance reuse by

allowing the same classextensions to b e applied to multiple classes

The pattern of passing the vo cabulary as an argument accomplishes the

eect of the this keyword found in many ob jectoriented languages It

ensures that micros can b e reused without having to know ab out all

future extensions Using this style programmers can also exp eriment

with interesting language extensions such as the lexical macros describ ed

in section

Validation Information is communicated through the attributes the threaded

attributes are fundamentally denotational or monadic in nature

The problems asso ciated with comp osing vo cabularies are thus the same as

those with comp osing arbitrary programming languages

There are some eorts to design sound typ e systems for mixins but these are

still preliminary Name resolution is currently done in the spirit of Bracha

rather than that of Flatt et al The latter will b ecome essential when

programmers try to integrate indep endently develop ed vo cabularies There are

unfortunately few typ e systems that typ e mixins in their own right and also sup

p ort the traditional functional typ es that have b een used to represent monadic

information Some of issues that arise from the interplayoftyp es and extensi

bility are discussed in greater detail by Krishnamurthi et al

Wehave purp osely restricted our attention to Scheme which has no native

static typ e discipline While the lackofatyp e system has obvious disadvantages

it has also had its b enets Because there are no candidate typ e systems that

cleanly capture all the prop erties of interest restricting ourselves to any one

typ e system would have complicated the design of McMicMacWewere instead

interested in rst studying the programs that generative programmers write and

can now fo cus on constructing a typ e system that supp orts such programs

Implementation Exp erience

Over the past veyears wehave implemented several generations of McMicMac

The current implementation consists of over lines of Scheme It includes

a standard system which consists of parsing vo cabularies for dierent parts

of Rices version of the Scheme including the func

tional core sideeecting features mo dules and signatures and the class system

The implementation is ecient enough for daily use as the core of a widelyused

programming environment DrScheme and as a prepro cessor byvarious

to ols including a stepp er static debugger and compiler Wehave also ex

ploited McMicMacs attributes to build pro cessors for typ ed languages notably

for a parenthesized representation of ClassicJava

Our implementation provides sourceob ject correlation and transforma

tion tracking which is extremely useful for interactive programming envi

ronments It eliminates most of the feedback comprehension problems present

in traditional macro and template systems All the to ols in DrScheme use this

information to provide sourcelevel feedback to the user This also greatly fa

cilitates linguistic prototyping for features that can b e translated sometimes

quite elab oratelyinto existing ones The translation ensures that we can reuse

existing to ols such as the static debugger and the source correlation hides the

complexity of the translation from the user

Related Work

The ideas b ehind generative programming have a long history Macros app ear to

have originally b een prop osed by McIlroy and a symp osium in con

solidated progress on extensible languages Macros have also had a long history

of use in various versions of Lisp and are incorp orated into

Scheme and others

C has recently added supp ort for a limited form of generative program

ming called templates These are intimately connected with the typ e system

of the language and are thus useful for describing typ ebased transformations

They have b een esp ecially successful at generating families of related comp o

nents

The Scheme programming language has oered some of the most innovative

macro systems Kohlb ecker and others intro duced b oth patternbased

rewriting and hygiene for macros Dybvig et al describ e a macro system

that oers some of the exibility of micros but without the structure Dybvig

et al present the rst sourcecorrelating macro system Taha and Sheard

have designed a macrolike system for ML that lets programmers nest metapro

gramming annotations to arbitrary depth and ensures that the resulting gener

ated co de is typ ecorrect Weachieve a similar eect using the static debugger

MrSpidey in conjunction with sourcecorrelation

McMicMac is also related to parser generators suchasYacc Several re

searchers have extended these works to adaptable grammars Some of the

most recentwork has b een done by Cardelli et al whichshows how similar

systems can b e constructed for nonparenthesized syntaxes While this system

can b e used to restrict and extend syntax it oers no supp ort for organizing elab

orator sp ecications analogous to McMicMacs attributes and do es not present

languages as mo dular layers

Our extensibility proto col is based on mixins which are a programming pat

tern used in Common Lisp and were rst formalized by Bracha The

use of mixins in McMicMac lead to a formalized mo del of mixins for a Java

like language Our proto col is closely related to that of Smaragdakis and

Batory which is a successor to the mo del of Batory and OMalley The

work most similar to McMicMac app ears to b e Batory et als JTS JTS shares

many common characteristics including the presentation of languages as layers

The emphases of the two systems app ear to b e slightly dierent JTS is con

cerned primarily with the construction of comp onent systems while McMicMac

concentrates on the programming forms that simplify sp ecications

Some researchers have prop osed using languages like Haskell and ML

for emb edding domainsp ecic languages employing higherorder functions the

languages ability to dene new inx op erators and in Haskells case laziness

to dene new notations These features are however not enough to con

struct abstractions like automaton gure Kamin and Hyatt describ e

the problem of lifting existing op erators to deal with domainsp ecic constraints

this can also b e addressed by generative programming Finally Kamin and Hy

atts language reects a common problem when language extensions cannot de

ne new binding forms Even though ML already has lexical environments they

must create their own metho ds and conventions for managing these thereby

inhibiting reuse

Conclusions and Future Work

Wehave describ ed McMicMac a generative programming system for Scheme

McMicMac extends traditional macrobased generative programming techniques

in several ways First it lets programmers attach attributes to sp ecications

whichprovides a way to propagate information during elab oration and to guide

elab oration itself Second it provides a structuring construct called vocabularies

Vo cabularies are analogous to mixins in ob jectoriented languages and p ermit

programmers to dene language fragments as comp onents that can b e com

p osed Wehaveused McMicMac to build several to ols including the widelyused

DrScheme programming environment

There are two main areas for future work First McMicMac is concerned with

generative programming in general and is indep endentofany notion of com

p onents It has b een used in the absence of comp onents within comp onents

and to generate comp onents Because linguistic abstractions are dierent from

traditional pro cedural abstractions the integration of comp onents with gener

ative programming can lead to unexp ected consequences that should b e studied

carefully

Second the McMicMac programming style is akin to that of Visitors

Some McMicMac sp ecications could b enet from more abstract sp ecications

such as adaptive programming The traditional presentation of adaptive

programming howeverdoesnotintegrate smo othly with the typ ed style of

sp ecication in McMicMac

Acknowledgements

We thank Robby Findler Cormac Flanagan and Matthew Flatt for their feed

backon McMicMacWe also thank the referees for their comments

References

Batory D B Lofaso and Y Smaragdakis JTS To ols for implementing domain

sp ecic languages In InternationalConference on SoftwareReuse June

Batory D and S OMalley The design and implementation of hierarchical software

systems with reusable comp onents ACM Transactions on Software Engineering

and Methodology Octob er

Bracha G The Programming Language Jigsaw Mixins Modularity and Multiple

Inheritance PhD thesis University of Utah March

Cardelli L F Matthes and M Abadi Extensible syntax with lexical scoping

Research Rep ort Digital SRC

Christensen C and C J Shaw editors Proceedings of the Extensible Languages

Symposium Asso ciation for Computing Machinery App eared as SIGPLAN

Notices August

Christiansen H A survey of adaptable grammars ACM SIGPLAN Notices

Novemb er

Clinger W D Prop er tail recursion and space eciencyInACM SIGPLAN

ConferenceonProgramming Language Design and Implementation pages

June

Czarnecki K and U Eisenecker Generative Programming Methods Techniques

and Applications AddisonWesley

Dybvig R K D PFriedman and C T Haynes Expansionpassi ng style A

general macro mechanism Lisp and Symbolic Computation January

Dybvig R K R Hieb and C Bruggeman Syntactic abstraction in Scheme Lisp

and Symbolic Computation Decemb er

Fairbairn J Making form follow function An exercise in

style SoftwarePractice and Experience June

Findler R B C Flanagan M Flatt S Krishnamurthi and M Felleisen

DrScheme A p edagogic programming environment for Scheme In International

Symposium on Programming Languages ImplementationsLogics and Programs

numb er in Lecture Notes in Computer Science pages

Flanagan C M Flatt S Krishnamurthi S Weirich and M Felleisen Catch

ing bugs in the web of program invariants In ACM SIGPLAN Conferenceon

Programming Language Design and Implementation pages May

Flatt M PLT MzScheme Language manual Technical Rep ort TR Rice

University

Flatt M S Krishnamurthi and M Felleisen Classes and mixins In ACM

SIGPLANSIGACT Symposium on Principles of Programming Languages pages

January

Gamma E R Helm R Johnson and J Vlissides Design Patterns Elements of

Reusable ObjectOriented Software AddisonWesley Personal Computing Series

AddisonWesley Reading MA

Hudak P Mo dular domain sp ecic languages and to ols In International Confer

ence on SoftwareReuse

Hudak P S Peyton Jones and PWadler Rep ort on the programming language

Haskell a nonstrict purely functional language ACM SIGPLAN Notices

MayVersion

Johnson S C YACC yet another compiler compiler Computing Science

Technical Rep ort ATT Bell Lab oratories Murray Hill NJ USA

Kamin S and D Hyatt A sp ecialpurp ose language for picturedrawing In

USENIX Conference on DomainSpecic Languages



Kelsey R W Clinger and J Rees Revised rep ort on the algorithmic language

Scheme ACM SIGPLAN Notices Octob er

Kernighan B W and D M Ritchie The C Programming LanguagePrenticeHall

Kohlb ecker E E D PFriedman M Felleisen and B F Duba

expansion In ACM Symposium on Lisp and Functional Programming pages

Kohlb ecker E E and M Wand Macrosbyexample Deriving syntactic trans

formations from their sp ecications In ACM SIGPLANSIGACT Symposium on

Principles of Programming Languages pages

Kohlb ecker Jr E E Syntactic Extensions in the Programming Language Lisp

PhD thesis Indiana University August

Krishnamurthi S YD Erlich and M Felleisen Expressing structural prop erties

as language constructs In European Symposium on Programming pages

March

Krishnamurthi S M Felleisen and D PFriedman Synthesizing ob jectoriented

and functional design to promote reuse In European Conference on Object

OrientedProgramming pages July

Lieb erherr K J Adaptive ObjectOrientedProgramming PWS Publishin g

Boston MA USA

McIlroy M D Macro instruction extensions of compiler languages Communica

tions of the ACM

Milner R M Tofte and R Harp er The Denition of StandardML MIT Press

Cambridge MA

Moggi E An abstract view of programming languages Technical Rep ort ECS

LFCS Lab oratory for Foundations of Computer Science UniversityofEd

inburgh Edinburgh Scotland

Smaragdakis Y and D Batory Implementing layered designs and mixin layers In

European ConferenceonObjectOrientedProgramming pages July

Steele G L Jr editor Common Lisp the Language Digital Press Bedford

MA second edition

Taha W and T Sheard Multistage programming with explicit annotations In

ACM SIGPLAN Symposium on Partial Evaluation and SemanticsBasedProgram

Manipulation pages

Wadler P The essence of functional programming In ACM SIGPLANSIGACT

Symposium on Principles of Programming Languages pages January