A SelfApplicable Sup ercompiler

Andrei P Nemytykh

Victoria A Pinchuk

Programming Systems Institute PereslavlZalesski Russia

Valentin F Turchin

The City Col lege of New York

Abstract

A supercompiler is a program which can p erform a deep transforma

tion of programs using a principle which is similar to partial evaluation

and can b e referred to as metacomputation Sup ercompilers that have

b een in existence up to now see were not selfapplicable this

is a more dicult problem than selfapplication of a partial evaluator

b ecause of the more intricate logic of sup ercompilation In the present

pap er we describ e the rst selfapplicable mo del of a sup ercompiler

and present some tests Three features distinguish it from the previ

ous mo dels and make selfapplication p ossible The input language

is a subset of Refal whichwe refer to as at Refal The pro cess of

driving is p erformed as a transformation of patternmatching graphs

Metasystem jumps are implemented whichallows the sup ercom

piler to avoid interpretation whenever direct computation is p ossible

Keywords program transformation sup ercompilation metacomputa

tion selfapplicaiton metasystem transition MSTschemes metaco de Re

fal patternmatching graphs

Contact Valentin FTurchin Hiawatha Blvd Oakland NJ

email Turchin turcccunyvmcunyedu

email Nemytykh nemytykhscpb otikyaroslavlsu

email Pinchuk pinchukscpb otikyaroslavlsu

Intro duction

Selfapplicabi li ty of a program transformer is well known to lead to new

p ossibilitie s such as automatic creation of compilers from interpreters see

Selfapplicabil i ty of a partial evaluator was rst achieved in

A supercompiler is a program which can p erform a deep transformation

of programs using a principle which is similar to partial evaluation and is

referred to as metacomputation Sup ercompilers that have b een in existence

up to nowsee were not selfapplicable this is a more dicult

problem than selfapplication of a partial eveluator b ecause of the more



intricate logic of sup ercompilation

In the present pap er we describ e the rst fully selfapplicable mo del of

a sup ercompiler We concentrate on the three features of this mo del which

distinguish it from the previous mo dels and make selfapplication p ossible

The input language is simplied to a subset of Refal whichwereferto

as at Refal Sec

The pro cess of driving see whichplays the key role in the

construction of the transformed program is p erformed as a transfor

mation of at patternmatching graphs which preserves their functional

meaning

Metasystem jumps as describ ed in are implemented Sec This

feature allows the sup ercompiler to avoid interpretation whenever a

direct computation is p ossible

In Sec the results of the testing of the new sup ercompiler are discussed

Flat Refal

For the purp ose of program transformation it makes sense to haveobject

programs written in a maximally simplied into

which programs written in a more convenient language can b e automatically

translated The sup ercompiler describ ed here uses at Refal as the language

of ob ject programs Flat Refal is used in two forms dierentinsyntax the

sentential form which is convenient for the human user and the pattern

matching graph form which is actually transformed in the sup ercompiler



Some steps in this direction though were rep orted in

symb ol symb olicname number character

expression term expression

term symbol variable expression

variable sindex eindex

index numbersymb olicname

functiondef fnname f sentences g

fnname symb olicname

sentences sentence sentence sentences

sentence leftside rightside

leftside rigidpattern

rightside expression functioncall

functioncall fnname expression

program sentence sentence program

Table The syntax of at Refal

Flat Refal is the lowest level in the hierarchy of the existing versions

of Refal which historically started from the basic version and was then

extended up as extendedRefal and down as strict and now at Refal We

wrote the programs constituting the sup ercompiler in extended Refal For

selfapplication we rst translate the sup ercompiler from extended Refal into

strict Refal this translation can b e fully automatic but in our tests it was

partly manual Then the text in strict Refal is automatically converted into

at Refal rst in the sentential form for debugging and then nallyin

the graph form in which it b ecomes an ob ject program for the higher level

sup ercompiler

Denition of basic strict and extended Refal can b e found in

A brief description of at Refal follows

The syntax of at Refal is given in Table The fundamental data struc

ture of Refal the expression is more general than the list or sexpression

used in Lisp and many functional languages It allows concatena

tion as one of the two basic constructions the other construction is enclosure

in parentheses which makes it p ossible to represent trees An expression

maybeempty in which case it is represented either by the metasymbol

or just by an empty space A string of characters can b e represented using

only one pair of quotes abc

The twotyp es of variables in Refal corresp ond to the two basic syntactic

typ es svariablessuchass or sx take exactly one symb ol as its value

evariablesase can haveany expression as its value

Denition

An object expression is an expression which includes neither variables

nor function calls

A rigid pattern is an expression such that a none of its sub expressions

has the form E ei E ei E where E etc are arbitrary expressions and

     

b no evariable app ears in the pattern twice 

The semantics of Refal is based on patternmatching We denote the

matching of an ob ject expression E theargument of the matching to a

o

rigid pattern P as E P This is an op eration the result of which is either

o

a substitution for the variables in P which transforms P into E in which

o

case matching succeeds and the substitution is referred to as its resolution

or a statement that there is no such substitution matching fails A pattern

can b e seen as a set of ob ject expressions Therefore we write E P if the

o

matching E P is successful

o

It can b e easily proved see that a matching E P where P is a

rigid pattern has no more than one resolution

Refal sentences are rewrite rules The sentences are tried in the order

they are written and the rst applicable sentence is used The righthand

side of every Refal rule in the at version of the language is either an expres

sion or a single function call nested function calls are not allowed Strict

Refal like at Refal requires that the lefthand sides b e rigid patterns but it

allows any combinations of expressions and function calls in the righthand

sides In at Refal information exchange takes place only through vari

ables not through the values taken by function calls This is an iterative

not recursive style of programming

We do not require though that the user writes programs in at Refal as

mentioned ab ove programs can b e written in strict Refal and automatically

converted into a at form The idea of the translation algorithm is to add to

each function one more argument which maintains a representation of the

stack of deferred function calls When the right side of a sentence in the

original not at program contains nested calls the function call whichis

to b e evaluated rst is left in the right side of the sentence all other calls

are reworked into stack elements and added to the rst argument in the

required order If the right side is passive a sp ecial function Pop is called

which p ops the stack appropriately We shall not go into details of the

algorithm but only consider as an example a simple strict Refal program

and its attening

Let function Fab b e dened by

Fab f

ae bFab e

s e s Fab e

g

In a given string of symb ols it replaces every letter a by b This program

is not in at Refal b ecause the recursiveright sides are not pure function

calls there is an invisible function which adds b or s in front of the

recursive call of FabWe treat function Fab as if its denition were

Fab f

ae Concatenate bFab e

s e Concatenate s Fab e

g

Concatenate f e e g

The translation of this denition into the at Refal is

Fab f

eSt a e Fab eSt Pop e

eSt s e Fab eSt Pop s e

eSt Pop eSt g

Pop f

eSt Pop eXXX Pop eSt b eXXX

eSt Pop s eXXX Pop eSt s eXXX

eXXX eXXX g

The initial call of Fab is now Fab e not just Fab easbe

fore where the empty content of parentheses stands for the initially empty

stack

If the rst symb ol of the argument e starts with a the rst sentence

of Fab works It adds the stack element Pop to the currentstack eSt

In this element Pop is the name of the function to b e called next formally

this should havebeen Concatenate but it has an immediate passive out

come hence Pop is called The symbol is just a case numb er Since there

are no variables in the deferred function call no more information is needed

than the function name This is not so in the second sentence where the

element togotothestackisPop s Here is again a case number

but the value of the variable s is also rememb ered

When the argument e b ecomes empty function Pop is called which

starts undoing the stack The variables of the form eXXXn stand for the

value of the latest call Lo oking at the rst sentence of Pop we see that

Pop is taken from the stack then b added on the left and the function

calls itself recursively The second sentence works analogously The stack

having b een exhausted the value of the initial function call is returned

We see that this translation simulates in an iterative manner the work

of a recursive denition

From the viewp oint of sup ercompilation the dierence b etween strict

and at Refal is not so salient as when we compare the resp ective program

ming styles With strict Refal congurations of the Refal machine include

deferred funciton calls which are in the previous sup ercompilers repre

sented byastack With at Refal congurations are at but the rst

argumentmay represent the same stack with which the strictRefal sup er

compiler is working The advantage of our present approach is that the

stack is not a separate structure but just one of the parameters It can b e

treated as other parameters which is causes considerable simplication On

the other hand if wewant to treat the stack as a separate structure we

still can do it in the at setting by giving a sp ecial treatment to the rst

argument

Patternmatching graphs

Belowwe briey describ e the most imp ortant features of a form of at Refal

programs whichwe refer to as at patternmatching graphs A program

in at Refal is automatically converted into a patternmatching graph

In our denition of the pattern matching E P the left side E was

o o

supp osed to b e an ob ject expression no variables Nowwe generalize this

concept byallowing patternmatching pairs where the left side E is an

arbitrary expression The variables in E are supp osed to b e bound ie

have denite values ob ject expressions The the execution ofgeneralized

patternmatching consists of two steps rst we substitute for the b ound

variables in E their values which results in some ob ject expression E

o

then we execute the matching E P where the left side is nowanobject

o

expression As a result of a successful matching the free variables in the

pattern P get certain values ob ject expressions again If there are no

variables in the pattern and the matching is successful as in aa the result

is denoted as Ithe identity op eration if matching fails the result is denoted

as Zimp ossible op eration

Denition

A contraction is a pattern matching v P wherev is a variable and P

c

is a rigid pattern we shall denote this contraction as v P

An assignment is a pattern matching E v where E is an expression

a

and v avariable we shall denote this assignmentasE v

The list of n Refal expressions E E E is the expression

  n

E E E

  n

A varlist is a list of free variables where no variable app ears twice One

varlist V isasubset of another V ifevery variable from V is also in V

   

Twovarlists are equal but not necessarily identicalifeach is a subset of the

other The list of all variables that enter a pattern E is denoted as varE

A list contraction is a pattern matching V P whereV is a varlist of

n variables and P is a rigid list of the same numb er of pattern expressions

c

We shall denote this contraction as V P

A list assignment is a pattern matching E V where V isavarlist

of n variables and E is an arbitrary list of the same numb er of pattern

a

expressions We shall denote this assignmentasE V 

We shall often skip the word list referring to contractions and assign

ments when it is clear from the context whether the op eration involves one

variable or a list of variables

Our notation of contractions and assignments mayseemunusual but it is

quite logical and convenient It is derived from the following two principles

On the left side wehave b ound old dened variables on the right side

free new to b e dened variables When the op eration is understo o d

as a substitution the arrow is directed from the variable to its replacement

To discuss the tests rep orted in the present pap er we only need to under

stand contractions and assignments and have a general idea of the syntax

of graphs

A patternmatching graph is a tree which represents p ossible computa

tion paths We write it in a syntax similar to that of arithmetic expressions

Terms in a sum are walks of the graph whichhave a common starting no de

Concatenation in terms represents sequential execution of the basic op era

tions while addition branching denes various p ossible cases Decisions

as to which of the paths is to b e taken are governed bycontractions and

restrictions the latter b eing essentially negative contractions Due to the

use of restrictions dierent branches starting at the same no de can b e pro

cessed indep endently This is not so in the case of the sentential form of

Refal where only those cases come to each given sentence which failed at

all preceding sentences

The function call to b e computed is given as a graph of the form

a

valuelist varlist fnF

where fnF stands for the graph dening the function F The nal result

of computation is assigned to the sp ecial external world variable eout

Metasystem jumps

In selfapplication of the sup ercompiler wehave a threelevel hierarchyof

functions f f f where f is some function f and f the sup ercompiler

     

In this hierarchy a function f at the level n is transformed by a function

n

f at the level n which is thereby a metasystem with resp ect to f

n n

Creation of each new level is a metasystem transitionorMSY for short

In a system was develop ed whichmakes it p ossible to automatically

change the level at which the computation is done we call this metasystem

jumps Thus whenever f is to evaluate partially f control is rst

n n

passed to f for a direct evaluation as far as p ossible When no step can b e

n

made b ecause of unknown values of variables control is passed backtof

n

for driving Examples in show that metasystem jumping may result in

a sp eedup factor of more than

The system develop ed in was used in the presentwork We refer the

reader to that pap er for details intro ducing only the notation used there

since we need it for discussion of tests

The domain of a function dened in Refal is a set of object expressions

Refal programs however may use most general Refal expressions including

evaluation brackets and free variables Hence we cannot directly write Refal

programs which manipulate Refal programs To do this wemust map the

set of general Refal expressions on the set of ob ject expressions and use the

images of hot ob jects ie free variables and evaluation brackets instead

of these ob jects themselves

We call this mapping a metacode and denote the metaco de transforma

tion of E as fE gif E is syntactically one Refal term the curly brackets

can b e dropp ed Obviously metaco ding must have a unique inverse trans

formation demetacodingsoitmust b e injective

E fE g

S S

si si

ei ei

E fE g

E fE g

E E fE gfE g

   

Table The metaco de

We used in the terminology of an internal metaco de dened by

Table where S is any symb ol and i the index of a variable

In the hierarchy f f f the function f has a metaco ded call of f

    

as its argument f has the metaco ded call of f as its argument We use

 



MST schemes for a clear representation of such hierarchies An MST

scheme is built according to the rule whenever a sub expression has the

form E fE gE the metaco ded part is moved one level down and replaced

  

by dots on the main level

E E

 

E fE gE E

   

The parts of the overall Refal expression which b elong to dierentmeta

system levels are put on dierent lines Refal expressions on the b ottom

level are written the same way as if they were on the top level metaco ding

is implicit and is indicated by putting them one line down Toconvert an

MST scheme into an executable Refal expression wemust metaco de each

level as many times as long is its distance from the top

In addition we can move up some variables in an MST scheme leaving in

the old place a bul let Ifavariable ti typ e t index i is raised by h levels

the n umb er referred to as its elevation then the meaning of the bullet

nh h

variable pair is fDn tig where Dn read Down is a Refal function

which p erforms the metaco de transformation on ob ject expressions Thus a

bulletvariable pair can b e seen as a variable metaco ded n h times but the



This notation was rst used by one of the present authors VT in lectures at the

University of Cop enhagen in Ever since its various versions were used in seminars

on Refal and metacomputation in Moscow and New York In a published form it rst

app eared in

p ossible values of this variable are only such that they an ob ject expression

h times In particular if an input variable is of an elevation h its desired

value must b e metaco ded h times b efore the b eginning of computation See

more ab out elevated variables in

Moving variables up radically changes the way the expression represented

by the scheme will b e executed To read an MST scheme correctly the

following rule of two levels can b e used

The variables on the top level arefree They are the arguments of the func

tion represented by the MST scheme as a whole some specic values must

be substituted for them beforecomputation The variables on the next level

down are the variables of the function whose denition the program for it

results from the computation on the top level

As an example consider the wellknown problem of compilation Let

L programdata b e a Refal interpreter of some language LLetP be a

program in L Using the sup ercompiler we can translate P into an ecient

program in Refal by partial evaluation according to the MST scheme

Scp

L P edata

Now supp ose wewanta function whichwould accept any arbitrary pro

gram not just P Ifwe simply put the variable program instead of P

Scp

L eprogram edata

we will not get what wewant Here the variables for data and for program

are on the same level and are treated in the same way Using the rule of

two levels we see that the result will b e a function of twovariables this is

again an interpreter No partial evaluation takes place b ecause the value of

eprogram remains unknown If wewant partial evaluation wemust raise

the variable eprogram to the level of Scp

Scp eprogram

L edata

Now the rule of two levels tells us that a sp ecic program will b e asked

by this function as the value of the argument eprogram Then partial

evaluation will take place returning a program for a function of the variable

edata It is of course a translation of eprogram The function dened

by this MST scheme may further b e sub ject to a transformation by another

partial evaluator It will then pro duce an ecient compiler for L

It should b e noted that in the calls of function transformers suchasScp

there is implicitl y one more argument which is not shown in our MST

schemes the denition program for all function calls on the ob ject level

Testing

Our system is still under debugging but we can already showa fewinterest

ing tests Wehave tested our sup ercompiler on several classical for partial

evaluation problems such as string patternmatching and compilation but

here we are concerned only with selfapplication and similar problems

Test

Before attempting selfapplication we ran a few tests which demonstrate al

most selfapplication a threelevel scheme where Scp transforms a metain

terpreter applied to some program One of the simplest tests is

Scp

Int ex

Fab

Here Fab is a simple function whichchanges every a to b Its denition

in at Refal is

Fab f e Fab e g

Fab f

e ae Fab eb e

e s e Fab e s e

e e g

Function Int is an interpreter of at Refal The argument x of Fab

is elevated by one level to b ecome free for Int and b ound for Scp The

call of Intby its denition computes Fab x with an arbitrary x by

interpretation of the program for Fab This function is equivalenttoFab but

works muchslower Transforming it by Scp returns an equivalent program

which is as it should b e exp ected an exact copy of the original program for

Fab except for the names of variables

Test

The sup ercompiler Scp at the top level of the MSTschemes in selfapplication

is denoted as ScpItwas written in extended Refal its volume sen

tences It was manually translated into strict Refal the volume b ecame

sentences Then it was automatically translated into a at form sen

tences which then was used as Scp to which Scp was applied Thus Scp

and Scp represent the same algorithm written in twoversions of Refal We

could use Scp in the place of Scp to havevery strict selfapplication

but weused Scp for the convenience of testing

In Test the scheme of selfapplication was

Scp

Scp

Fab e

This is a correctness check All work is done by Scp with Scp as a

simple sup ervisor We see from the rule of two levels that Scp is a function

of no variables a constant whose value is the denition of a function of

e which is equivalenttoFab The sup ercompiler on the level Scp has

no free variables on either top or the next level it transforms a function

namely Scp which is a constant The output of Scp is not the same

as the output of Scp b ecause they are on dierent metasystem levels If

Scp is the constant const then Scp outputs the metaco de of a program

a

in the graph form which outputs const ie fconst eoutg

The actual output of the sup ercompiler is however a bit more complex

The program pro duced by the sup ercompiler can b e seen as the expression

Define def f deff Call G

 n in

which combines a list of the denitions of new functions f and the initial

i

function call to compute G The function denition is of the form

in

def f muConfig Fni fProg g

i i

where Config is a recurrent conguration in terms of the initial pro

gram Fni is the symb olic name of the corresp onding new function f and

i

Prog the program for it

i

The output of the ndlevel sup ercompiler Scp is a metaco ded program

whichwe shall denote as fProggInTest it is this

a

fProgg Define Call ffProgg eoutg

This program simply outputs the metaco ded program Prog

fProgg Define FabeeFnfProgg

a

Call feeefnFng

Program Prog is the result of sup ercompilation by Scp of the call Fab e

therefore it must b e equivalent to it Prog denes one recursive function

Fn which is the sup ercompiled function call Fabee The vari

ables of this conguration b ecome the variables of the denition of Prog

Therefore the initial call is a call of Fn after the necessary assignments to

the variables ee The program Prog is the program for Fnit

results from sup ercompilation of Fab and it is identical to it except for the

dierent names of variables This is exactly what one should have exp ected

Test

The MST scheme in this test is

Scp

Scp s

Fab e

Here the argumentofFab is s e ie it starts with some symbol

s Wehave raised s to b ecome a free variable in the call of Scp

According to the Rule of two levels the result of Scp must b e a function

of s The actual output is

Prog Define Call fProgg

where Prog is the initial graph whichwe present in the sentential form for



readability

Prog f

a Define Fab beFn P r og

a

Call feee fnFng

s Define Fab seFn P r og

a

Call feee fnFng

g

We see that Prog indeed dep ends on s and includes two cases where

its value is aoranyvalue distinct from a In b oth cases the structure

of the value is similar to that in the preceding test The dierence is that

partial evaluation to ok place with resp ect to s Lo ok at the recurrentcalls

of Fab it is already within the parentheses which enclose the ready part of

the string changed to b if it was a The programs Prog and Prog

for Fn and Fn resp ectively are

Fn f

e ae Fn eb e

e s e Fn e s e

e be g

Fn f

e ae Fn eb e

e s e Fn e s e



e fsg e g

These programs are the same as the initial program for Fab except

that they are mo died b ecause of the partial evaluation which to ok place

Functions Fn and Fn dep end on e alone s has already b een pro cessed

and is kept in the rst argumentof Fab When the string is exhausted and

the output is done s must b e added at the b eginning of the string resulting

from pro cessing econverted to b in Fn or left unchanged in Fn

The variable s enters the program P in the negative degree of meta



co de This is the result of the variable s b eing elevated Recall that the

meaning of a variable elevated by h levels and metaco ded n times is

nh h

fDn sg In our case h andn When fProgg which

is yielded by Prog is demetaco ded the metaco de level from b ecomes

but the elevation h remains which means that the value of s isameta

co ded once symb ol When it is substituted by Progin fProgg and

fProggwehave a correct all on the lev el program When it is

demetaco ded as a whole the result will b e a correct working program level

the value of s will b e demetaco ded together with the rest of the pro

gram However if wewant to write down the demetaco ded program for Fn

for an arbitrary swemust insert in the prop er place the demetaco ded



symb ol which is the value of s This is exactly what fsg means

It should b e noted that with our metaco de symb ols do not change under

metaco ding or demetaco ding Yet it would b e an error to put s instead



of fsg b ecause s is not a free variable in the denition of Fn

The sentence which results from such a replacementwould b e syntactically

faulty the right side of the sentence would include a variable whichdoes

not enter the left side

Test

The MST scheme is

Scp

Scp e

Fab

Here wehave elevated the whole argument e Because of this Scp is

not transforming the program for Fab It has no b ound variables therefore

the call of Fab is a constant for it What is going on is this Scp gets a value



E of e at input computes the value E Fab E and then outputs a



program which outputs the constant E AsforScp it outputs a program

which is equivalenttoScp ie it do es the same thing but muchmore

eciently ideally as ecient as the function Fab itself outputs is value

The actual result of sup ercompilation is

ProgDefine C onf Fn fProgg

a

Call feee fnFng

Here C onf is one of the congurations in the sup ercompilation of Scp

by Scp It is big and hardly manageable byahuman user When Scp

works on Scp it nds recurrent congurations which b ecome new recursive

functions Conf is such and the only conguration The only thing ab out

it that is easy to establish is that it includes two free variables e and

e

The program Prog is

Fn f

e ae Fn eb e

e s e Fn e s e

a

e Define Call e feoutg

e Define Call Z g

Since the variable e has the elevation its intended value must b e

metaco ded b efore the computation by Scp This remains true also for

Scp b ecause it pro duces a program which faithfully follows the input

output requirements for Scp

At the rst glance it may seem that the assignment in the third sentence

of Fn has an error the output variable eout is metaco ded while e

is not But e is like e elevated indeed it is the result of pro cessing

e and the initial value assigned to e is eFunction Fn outputs

a metaco ded program When it is demetaco ded feoutg b ecomes eout

and the value of e is demetaco ded So the result is as it should b e

Function Fn mimicks the recursive function Fab except that it has

one more sentence the fourth This also is a consequence of the fact that

Scp works in metaco de Fab is dened in exp ectation that its second

subargument is always a string of symb ols If it starts with a parenthesis the

Refal machine fails comes to an abnormal stop the value of the function

in this case is not dened But when Scp works in metaco de and discovers

a parenthesis it does not fail In our language of graphs there is a sp ecial

op eration for this situation Z This is our waytosay in metaco de that the

original function causes failure So if none of the rst three sentences of

Fn works then the fourth sentence assigns Z as the output value

It is interesting to compare Tests and with regard to the level at

which recursion lo ops are closing The Define part of the output consists

of those congurations whichwere found recurrent In Test the function

transformed by Scp dep ends on a symbol variable only there is no recur

sion on this argument see the MST scheme Therefore the Define part

of the output is empty The function transformed by Scponthecontrary

dep ends on an evariable thus on this level wehavetwo recurrent congura

tions Fn and Fninthe Define part In Test Scp works on a recursive

function of an evariable hence the app earance of recurrent congurations

is inevitable

Test

The next two tests demonstrate another use of a sup ercompiler in a com

bination with a nonstandard interpreters of the ob ject language Our lan

guage at Refal do es not allowustomake lazy evaluation To amend this

wehave written in at Refal a lazy interpreter LazyInt of a full functional

language strict Refal Given a program in strict Refal weinterpret it by

LazyInt and sup ercompile this pro cess by Scp according to the following

MSTscheme

Scp

LazyInt e

Fbc Fab

The program which is implicit in the call of LazyInt denes two func

tions Fab and FbcFunction Fab was dened in Sec as an example of a

nonat recursive function

Fab f

ae bFab e

s e s Fab e

g

It replaces every a by bFunction Fbc is dened analogously and re

places every b by c The lazy interpreter works on the comp osition of

these two functions The exp ectation was that after sup ercompilation we

should have a at onelo op program which converts b oth a and b into

c

And indeed the resulting program is exactly as exp ected

Fac f

e FC e g

FC f

e ae FC e ce

e be FC e ce

e s e FC e s e

e e g

It transforms a twopass program into an equivalent onepass program

Test

In this test we use the sup ercompiler in a combination with an even less

standard interpreter an inverse interpreter InvInt which executes a func

tion denition in a form of a graph from its ends to its b eginnings and

computes the value of the input when an output is given InvInt stops

after nding the rst solution and is relatively simple b ecause wehave put

rather strong constraints on its input a program to in vert They are

The program must b e in at Refal

The right side of each sentence or the argument of a function call in

the right side must b e a rigid pattern

All variables of the left side of a sentence must b e met also in the right

side

The MSTscheme in Testwas

Scp

InvInt e

Rev ex

The interpreter InvInt exp ects a conguration which dep ends on the

input variable ex and the output value assigned to the free variable e

Implicit in the call is the program which denes the function Rev

Rev f ex Rev ex g

Rev f s ex ey Rev ex s ey

ey eY g

The interpreter nds a value of ex such that

Rev ex e

and gives it out as its value

Function Rev reverses its argument Since its reversal is itself the b est

we can exp ect from the sup ercompiler is that it returns a function denition

identical to the ab ove program for Rev And it do es so



We can see this result as a pro of that Rev Rev and therefore a pro of

that RevReve is the identical function It shoud b e noted that this

double reverse conguration cannot b e reduced by direct sup ercompilation

to the identical function ev en such a function that passes through the

string symbol by symb ol without changing them

Conclusion

What wehave shown in these tests is the hard core of the sup ercompiler

system For sp ecic applications sp ecial front and back ends can b e added

For instance the system requires that the value of an elevated variable

b e metaco ded at input and demetaco ded at output Clearly this can b e

included into the system and the end user need not knowanything ab out

this MSTschemes can also b e formed for a wide class of problems without

b othering the user with such details

Our tests show that a sup ercompiler can b e selfapplicable The im

p ortant thing here is not of course just to apply it to itself and obtain

some target program this program must b e a go o d ecient program We

gave examples of such nontrivial transformations A big program Scp

is applied to a big program Scp itself or a nonstandard interpreter and

pro duces a small residue which is the desired solution to the problem Sure

enough the zerolevel programs in these tests are still small not big but

we b elieve that this is a matter of some technical details eliminating bugs

and netuning some of the algortihms such as generalization Writing su

p ercompilers like writing compilers is a technology It develops slowly but

surelybyaccumulating small discoveries and improvements

Acknowlegements First tests of the present sup ercompiler were discussed

in the summer of in Cop enhagen Moscow and Pereslavl Russia The

authors thanks the participants esp ecially Sergei Abramo v Sergei Chmu

tov Rob ert Gluc k Neil Jones Andrei Klimov Arkadi Klimov Torb en Mo

gensen Sergei Romanenko Morten Srensen for useful commen ts

References

Ershov AP On the essence of compilation In EJNeuholded For

mal Description of Programming Concepts pp NorthHolland

Futamura Y Partial evaluation of computation pro cess an approac h

to compiler compiler Systems Computers Controls pp

Jones N Sestoft P Sondergaard H An exp eriment in partial eval

uation the generation of a compiler generator In Jouannaud JP

Ed Rewriting Techniques and ApplicationsDijonFrance LNCS

Springer

Jones Neil The essence of program transformation by partial evalua

tion and driving In Proc of The Atlantique Worlshop on Semantics

BasedProgram Manipulation NJones and CTalcott Ed Cop enhagen

University pp

Gluc k R Towards multiple selfapplication Proceedings of the Sym

posium on Partial Evaluation and SemanticsBasedProgram Manipu

lation Yale UniversityACM Press pp

Gluc k R and Klimov And Occams razor in metacomputation the

notion of a p erfect pro cess tree In Static Analysis COusot etal Eds

LNCS Vol pp SpringerVerlag

Gluc k R and Srensen MH Partial deduction and driving are equiv

alent In Symposium on Programming Language Implementation and

Logic Programming PLILP LNCS SpringerVerlag

Gluc k R and Turchin V Exp eriments with a Selfapplicable Sup er

compiler CCNY Technical Rep ort

Turchin VF Equivalent transformations of recursive functions dened

in Refal In TeoriyaYazykov I Meto dy Postro eniya Sistem Program

mirovaniya Pro ceedings of the Symp osium KievAlushta USSR

pp in Russian

Turchin VFKlimovAVetal Bazisnyi Refal i yego realizatsiya na

vychislitelnykh mashinakh Basic Refal and its implementation on com

puters GOSSTROY SSSR TsNIPIASS Moscow in Russian

Turchin VF The Language Refal the Theory of Compilation and

Metasystem Analysis Courant Computer Science Rep ort New

York University

Turchin VF Nirenb erg RM Turchin DV Exp eriments with a

sup ercompiler In ACM Symposium on Lisp and Functional Program

ming ACM New York pp

Turchin VF The concept of a sup ercompiler ACM Transactions on

Programming Languages and Systems pp

Turchin V Refal Programming Guide and Reference ManualNew

England Publishing Co

Turchin V Nemytykh A Metavariables Their implementation and

use in Program Transformation CCNY Technical Rep ort CSc TR