Table Of Content.K:i.-x••. ».;•/.
Computer Science Department
TECHNICAL REPORT
Comparing Three Approaches to
Transformational Programming
Konstantin Ldufer
Technical Report 555
April 1991
NEW YORK UNIVERSITY
0)
x:
u
(0
o
U rH
Q4 c
lin -H (0 o
l|\ifUnIn 44c(-J0> £((i1-U>ir4(e-H0) •
|iu-i CcoO 4-1 io-i CcP Department of Computer Science
en w e
c s Courant Institute of Mathematical Sciences
llOu V<Ju (0 4-1 251 MERCER STREET, NEW YORK, N.Y. 10012
e o
>H (T3 uO 4-1
Comparing Three Approaches to
Transformational Programming
Konstaniin Ldufer
Technical Report 555
April 1991
Comparing Three Approaches to
Transformational Programming*
— —
Preliminary Version
Konstantin Laufer
Courant Institute ofMathematical Sciences
New York University
715 Broadway, 7th floor
New York, New York 10003, USA
laufer@cs.nyu.edu
April 22, 1991
Abstract
Transformationalprogrammingisamethodologythatintendstoformalizethedevelopment
ofprogramsfromproblemspecifications. Giventherecentefforttowardsthedesignofacommon
prototypingsystem (CPS) forthe Adaprogramminglanguage,transformationsystems may be
reconsidered aspossiblecomponentsofprototypingsystems. Thispaperexaminesandevaluates
three approaches totransformationalprogramming:
• The Munich GIF project (Gomputer-aided, Intuition-guided Programming) consists ofa
strongly typed, wide-spectrum language with user-defined algebraic types and a semi-
automatic transformationsystem that requires user guidance.
• By contrast, "Algorithmics," the work on algebraic specification originating from IFIP
WG
2.1,isapurepencil-and-paperapproachtotransformationalprogramming. Itprovides
aconcise, uniformmathematical notation andincludeswork onnondeterminism.
• RAPTS (Robert A. Paige's Transformation System) is a fully mechanical system that
transformshigh-levelspecifications to Gcode. Thespecificationsaregiveninafunctioned
subset ofSETL augmented with fixed-point operations.
First,wedescribeeachsystemindeteiilandhighlightinterestingfeatures. Next,weestablish
aframeworkofcommoncriteriabywhichsuchdifferent transformationalsystems can beevalu-
ated. Finally, we point out commonfeatures and differences ofthe three systems and compare
them.
'Supported inpart by the Defense Advanced Research Projects Agency/Information Systems Technology Office
under the OfficeofNavalResearch contract N00014-90-J-n]0
1 Introduction
Programmingisacomplextask;largeprogramsaredifficulttoproduce,andonceproducedtheyare
oftenimreliableeindexpensivetomjiintainorimprove. The "softwarecrisis"reni£iinsanimportant
issueinsoftwareengineering. Aleirgeamountofresearchhas been goingontoovercome this crisis:
On one hand, a considerable portion ofthe work has focused onformalizing and automating the
software development process; on the other hcind, prototyping has been promoted as a method of
obtaininginformationabout aproblembefore implementingit inaproductionlanguage.
Traditionally, programs have been verified experimentally by choosing anxmiber ofinput test
cases, running the program, and evaluating the resiilts. The problem with this approach is that
it can never formcilly prove the correctness of the program. There might always be cases not
capturedby thetest data. Prototyping attempts tocatcherrorsat anearly astageoftheprogrsim
development.
Formal verification, on the other haind, is an analytic process that defines in mathematical
terms what it means for aprogramtobe correct, givenamathematiccildefinition oftheprogram-
ming lainguage used, and aformal specification ofthe problembeing solved. However, the formal
verificationoflargeprogramshas turned out tobe impractical.
By contrast, the transformationalapproach (see [PS83] for an excellent survey) is a synthetic
or constructive one. Aprograimis derivedfromaproblemspecificationby successiveapplicationof
correctness-preservingtr£insformationsthatleadtoacorrectimplementationoftheproblem. Akey
point is the reusabilityoftr£insformationrules; once anile is proven correct, it can be used again
ifapplicable tothepzirticidar situation. Libraries ofknown transformationscanbe established; as
the libraries grow, the number ofnew proofs required in the development ofaprogramdecreases.
An advantage oftransformationalprogreimmingis the tight coupling ofprogram development
and verification. A complete progreim consists ofthe specification, the final executable program,
and the complete history ofintermediate transformations. This history serves as a program doc-
umentation, since it captxires all ideas and decisions relevant for the program. Later modification
is facilitated because it corresponds to stepping back in the development and following an other
branch at apoint where a decision was made.
The trainsformational pciradigm leaves a lot ofroom for automation; the programmer can be
relieved of tedious tasks that come up during prograim development such as rewriting progreim
pieces,verifyingapplicabilityconditionsoftrjinsformations,reviewingthedevelopmenthistoryetc.
However, important design decisions are generallyleft to the progrcimmer.
Recently,aconsiderableeff'orthasbeenmadetowardsthedevelopmentofacommonprototyping
system (CPS, see [Gab88]) for the Ada language. As a future goal, we would like to explore how
a transformational component ccin be incorporated into such a prototyping environment. The
trEinsformationcd system cotdd be used to aid replacing pieces ofthe prototype by more efficient
pieces obtainedby transforminginto a tjirget language.
From this perspective, we take a detailed look at several approaches to transformationalpro-
grammingin thenext three sections, emphasizingrelevant features. Li the last section, wepresent
aframeworkofcommon criteriafor the comparisonoftransformationjilsystems. FineiUy,we apply
these criteria to the systems under consideration.
2 The Munich CIP Approach
The CIP project was created with the goal ofproducing an implemented software development
system using the trsinsformational paradigm. CIP stainds for "Computer-aided, Intuition-guided
Programining". The project consists oftwo components: The wide-spectnim programming lan-
guage CIP-L [B+85a], and the program-transformationsystem CIP-S [B+87a]. The user ofCDP-S
specifiesaproblemin CIP-L and derivesa (hopefully efficient) implementationofthe problem.
A wide-spectrum language is a single formal Icinguage which includes specification constructs,
implementationconstructs,andcinyintermediateconstructsneededforprogramdevelopment. The
use ofsuch a liinguage makes it easy to formulate program transformations as locaJ, correctness-
preserving, source-to-source trcinsformations on a common semantic basis. CIP-L is a scheme
language, i. e., a language without a fixed set of basic data types. This makes it possible to
manipulateprogramschemes which can later be instcintiatedas needed.
ThesystemCIP-S isaninteractivesystemwhosepurposeistoassist theprogrammerinclerical
work cind other tasks that can be automated. It performs routine tcisk such as keeping track of
various versions ofa program, and it provides a mechanism for performing transformations. In
addition, it helps theuser verify the applicabilityofatransformationto aportionoftheprograim.
It also maintains a library oftransformationrules and assists in searching the library. Decisions,
however, are eJwaysmade by the user; he or she supplies theintuition.
It isinterestingtonotethat the CIP systemwas developedusingexactlythe CIPmethodology.
First, a formal specification of CIP-S was written, which includes a logical calculus for progrcim
tremsformations. Then, aprototypeofthesystemwasderivedfromthespecificationusingprogram
trainsformations. The systemhas not yet reached its fined state; therefore peirts ofits description
below refer to the specificationrather thcin the implemented system.
For a detaUledevcJuation ofthe CEP project see [WJS87].
2.1 The System CIP-S
The purpose of CIP-S is the transformational development ofprogrcim schemes. This includes
manipulationofactuaJprogrjims, derivationofnew transformationrules withinthe system, trans-
formationofalgebraic types and type schemes, and verificationofapplicabilityconditions.
TransformationndesinCIP consistofthreecomponents: inputtemplate,outputtemplate,and
applicability condition. The input aind output templates axe program schemes, possibly including
context parameters, which allow the user to mark fragmenteiry terms (contexts) as replaceable. A
typical rule, for example, expresses the distributivity of the conditional expression over varying
contexts:
F[if C then A else 5 fi]
I
if C then F[A] else F[B] fi
Under this rule, the code fragment
X := if z > 3 then 4 else 2 fi
is transformed to
if I > 3 then x := 4 else x := 2 fi.
Inadditiontosuchniles, CIPprovidesametcdcinguagefor transformationexpressions,whichallows
transformationalalgorithms to be expressed similarly toregideir expressions.
Thetransformationrulescireorganizedasgenerativesets,i.e.,asmcdlsetofpowerfulelementary
transformationsthat canbe used toconstructnew riiles. Thebasicnilesincludegenercdprinciples
(such as unfold, fold), the definitioned ndes ofthe language, and the axioms and inference niles
of the predefined types. Furthermore, some frequently used derived niles, as well as standard
implementation techniques for some abstract types, aire available. CIP-S allows the user to define
new transformationniles aind mmntainlibrziries ofrules.
CIP-S records the whole development ofa programfroma specification. It allows the user to
browse through the development, backtrackand continue withanotherprogramversion,return to
previous development steps etc. The system assists the user in the selection and application of
traoisformationrules. All this calls for a sophisticated interactive user environment on top ofthe
system core. This environment makes use offacilitiessuch as graphic screens, windows, and mice,
and aJlows the user to performail the systemfunctions conveniently.
There aie severed languages involved in the design ofCIP-S. As the object language, the lan-
guage for formulatingprogramschemes, an jJgebraically defined languageis assimaed. CIP-L was
designed especially to serve this purpose. Transformation aJgorithms are formulated in a special
metalanguage,whichconsistsofconstructssimilartoregularexpressions,overtransformationrules
as described above. This language is supposed to be later replaced by a simple applicative lan-
guage. Finally, the Izmguage for enabling conditions oftrzinsformationrules consists ofpredicates
over terms ofthe object language.
Note that CIP-S is extensiblewithrespect tothe transformationlibreiries,object languageand
user environment. Since CIP-S is beingusedforits owndevelopment,it isevenpossible to change
the implementationlanguage by going back to the stage before fixing the lauiguage, and changing
to adifferent Izinguage.
2.2 The Language CIP-L
In order toaccommodateafullvarietyofprograimmingstyles,the CIP group conceived thenotion
ofawide-spectrumlanguage, asinglelainguageprovidingailthe stylesrequired,fromspecification
level downtoimplementationlevel. CIP-L has the followingcomponents:
1. Algebraic or abstract data types. Types provide the means for specifying basic objects and
operations on those objects. They determine the applicationfor thelanguage.
2. Theschemelanguage. ThislanguageistheheairtofCIP-Landprovidesthemeansforwriting
specifications and algorithms. It is structured hierarchically with levels from specification
through application, procedure down to control. The specification level is Ccilled kerneland
consists ofexpressions over the basic types.
3. Programs. Programsconnect thefirst twoparts ofthelanguage. A programis afinite set of
components, whichmay be types, computationstructures,modules or devices. Computation
structures, modules and devices are implementations ofthe basic data types underlying the
scheme lemguage.
The language is defined formally. Algebraic data types cire defined through algebraic seman-
tics. Only the kernel of the scheme language is defined through traditional denotational seman-
tics [Sto77,Gor79]. The additionallevels are defined in terms oftheprevious levels by transforma-
tional semantics.
CIP-Lhasanabstract syntax,henceitsexternalrepresentationisflexible. Thelainguagecanbe
represented by an ALGOL-likeor Pascal-likevariant,orevenby aLISP-likeorProlog-likevariant,
depending on what the particular application calls for. All that is required is an appropriate
parser/unpaxser.
OthernotablecharacteristicsofCIP-Larefulltyping,modularity,providedbyalgebraictypeson
the specificationleveland by computation structures,modules and devices (modules withinternal
state) on theimplementationlevel, and nondeterminism.
Itisnotsiu-prisingthatsomemodemprototypinglanguagesaredesignedsimilcirly;forexiimple,
the prototyping language Griffin [D+90], currently under development at New York University,
shares several key features with CIP-L: strong typing, user-defined algebraiic data types, £ind a
layered semantics.
We willnow excimine the three components ofCIP-L in detail.
2.3 Abstract Data Types
Inprogramscertainidentifiersareusedforobject sets (sorts),forelementsofthesesets (constants),
andforfonctionsoperatingonthem(operations). Beforewegiveaninterpretationtothesesymbols,
wearedeeding withprogramschemes. Thepurpose ofabstract typesis togiveaninterpretationby
presentingthesorts,constcintsandoperationswiththeirfunctionalityandbystatingtheproperties
informofaxioms (laws). Abstract types may be constructedhierarchically.
Anabstract type, briefly called type, consists oftwonoainparts:
• The signature, which is a list ofsymbols whose meaning is specified within the tjrpe. Each
s)anbolis associated with aspecification ofits kind (sort or carrier set ofan abstract type):
Symbols for sorts aire given as attributes the kejrword sort, symbols for constemt elements
their sort, and operation symbols are given their functionality. A subset ofthese symbols is
made visible to the outside by the list ofconstituentsofthe type. Symbols not made visible
arecalledhiddensymbols. Thesignaturedeterminesalanguageofwell-formed terms(formed
fromthe constants by applyingthe operations) whichmay alsocontaiinfree identifiers.
• The collection oflaws, which specify the properties ofthe symbols. The laws arefirst-order
logicformulasbuiltfromequationsandinequalitiesandlogicaloperators A, V, =>, •«>,andof
the qucintifiers V, 3, over sorts ofthe type.
The meaning ofa tjrpe T is defined to be the class ofall term-generated models ofT. Note that
there might be many different taodels for a type T, or there might be only one, depending on the
particular set oflaws supplied.
Forexample, thefollowingtype specification describes integer arithmeticmodulo 3:
type MODS =
modZ,zero,one,two,succ:
sort mods,
mods zeTo,one,two,
funct (mods) modS succ
laws mods x,y
:
zero ^ one,
zero / two,
one ^ two,
succ{zero) = one,
succ{one) = two,
succ{two) = zero
end oftype
IthasthevisibleconstituentsmodS,zero,one,twoandsucc,wherezero,oneand twoareconstants
ofsort mods, and succis afunction tciking one modS parameter and returning a tnod3.
A type T may depend on other types in three ways:
type inclusion: AtypeTcanbemadeavailablebyaninstcintiation,possiblywithreneiming,using
anincludeclause. Suchaninstantiationisequivalent tothetextualsubstitutionofthebody
ofT (withconsistentrenaming); thereisnoprotectiononthemodelsofT.Instantiationsaxe
simplya shorthandnotationfortype bodies; they havenoindependent semantics.
base types: A type may use another, "primitive" type by means ofa based on daixse. In this
case, the primitive type is protected agcdnst modifications ofthe carrier sets ofits models.
This is called hierarchy preservation and guairantees independent implementability of the
primitivetype. The typesmentionedinthe based on clause shouldbe thought ofaspeirtof
thenew type.
type parameters: Typespecificationsmaybepaireimetrized. Theparaimeterscanbesortsymbob,
constaint symbols, and operation symbols. They are attributed in the same way as withina
signature. Such tjrpe specifications eire called type schemes or generic types. They may be
instantiatedbothin based on clauses and includeclauses.
Modesaie a shorthandnotationfor certain types and type schemes whicharefrequently used.
Modes are syntactically introduced by (possibly recursive) mode declarations. The semantics of
mode declarations is explained by instantiationofthe associated types; thus recursive modes are
explainedina straiightforwardmanner. There are twobasic kinds ofmode declarations:
sum: AsumisadisjointunionofafinitenumberofVciriantscindcomeswithconstructors,projec-
tions,andboolecin test functions, whichindicatewhether anintendedprojectionwouldyield
a defined result.
product: A product is a finite, heterogeneous tuple. A product has a constructor function and
component selectorfunctions.
For practical purposes, the programming system for the language should provide a collection
ofpredefined types as a basis for further programming activities. Typical staindard types include
boolean values, integers, finite sets and multisets, finite mappings, sequences, trees, pointers and
pointer structures.
2.4 The Scheme Language ofCIP-L
We wiU present the different style levels of the scheme language and give examples. For most
exajnples, we willuse am ALGOL-like representation.
2.4.1 The Expression Language for Logic and Functional Programming
An expression denotes objects ofa certciin kind (e. g., a sort ofein algebraic type). Fundamental
expressions are the terras overbasic object and operationsymbolsofanimderlying algebraictype;
these symbols have to be interpreted in some model ofthat type. Other examples ofexpressions
foUow:
Guarded Expressions. The guarded expression has the followingform:
