- Email: [email protected]
A classification of extensible programming languages
INFORMATIONPROCESSINGLETTERS 1 ( 1972) 91-96. NORTH-HOLLANDPUBLIf HlhJGCWPANY
N. SOLNTSEFF Lkpwtment
tf
Applied MU *hemarks, MiMaster
Universitv, ;/amilton,
Ontario, Canada
Received 30 September 197 I
exten$ble languages programming languagesclassification
The need for a classification scheme for extensible prograrr.ming lank*lages has become apparent because of their growing numbers. The formal methods used to describe programming languages [28] have not addressed themselves to the problem osextensibility largely, it seems, because in Wegner’s words “Mathe-’ maticians regarda defiiition as a form of abbrevia- l tion \4kh sometimes provides useful insights by associating a name with an intuitively importandconcept, but which does not add vy new content $I the theory”. It is thus very easy to dismiss the problem of definition as being trivial since a defined term can be everywhere replaced by the aerms used to define it, so that definitio,)ris considered merely as a shorthand for reducing the length of texts. The author has been able tb find only t#o papers giving a formal description of extensiblg langkges [ 10, 171. These papers describe only one approach to l language extensiiility~ In the first, Letichevskii adopts a set-theoretic approach to the description of macroextensible languages, while the second gives a description of the PL.0 compile time facility [ 141 in the Vienna Defmition Language [ 181. AJtiough the early proposals for programrning4angu~~eextension [ 7, 16, 19] were based on the use of macro processors [S] , ’ some of the more recent proposals (for example, see 19] ) involve mechanisms which are difficult to fit into *The work described here was performed while the author was in the Department of Electrical Engineering, University of Colorado. +Revised version of paper presented at the Internationlll Symposium of Extensible Languages,Grenoble,@terr.ber 3-5, 1971.
macro
formal model
translation extension mechanism
this classification so that a broader framework is req;lired. A clas,’SIfrcat ion izheme which fias helped the author the introduce riozje order intc the existing and proposed extensible languages is given below. In the absence of a formal model of language extensibility, it is necessary to adopt a qualitative approach and to aim at the construction of a model suitable for the comparison and evaluation of implemented and proposed extensible languages. A convenient framework is the translation process by which i: “source” program is converted into a “target” program capable of being run on 3 hardware machiru . A program in an extensible language consists of a combination of a base texf B in the base language&$ (the language bt)i extended) and an arrgmeuttexf A expressed in term7- of constructs which Jre not part of &, but which have been suitably defined. The text A may be considered to be in an augment language 4$. A and B together form a text E in an extetrded far?guageSe. The language into which L!a is converted by an extonsion may be called the derived Imguage. The definitions form a text D which may be a part of either A or B. This second augment D is a text in a defirzitiorthguage Gd which. in genera!. will be distinct from Pa and L?b. If, however. ~2~C 2,. then the base language can be terme,d to be sc!j:exterlditlg.It should be noted that statements in .@aarc in the INture of declarations since t!iey do n&t give rise to executable code, although they zffect the cou:sr;- of the translation process once they are encountered and thus affect the form of the target program. ’ nle classification of the extension mecl:ilnisms CM be made on the basis of the stage of the tra&tiulI
N. Solntseff) Ck&fication of exteatsibk prvqamming hmguages
32
_
Table i Type-A tx tensibk languages. __---__--__ -0
_~-----~----_-.--Derived Base language language
Mcllroy [ 191
2s ze 33 2s v3 I
.-p-y.
- __.-- -_v -
-
“2 4% $2 3% rfi & i3 ar::
Any
CZ 22 23 k”3w
&Yes
Yes
Base language
Yes
Yes
RJ lang&e
Yes *
Extension Methods
Yes
Text macros
High level with conditional replacement
Text macros
No co ditionalTepiacenient
Semi-@ntactic macros
No conditional replaQement
14
-e
_
Yes
” &es
..
which the definition o,i an extension is e there are six identifiable stages in the ocess, namely, lefticalanalysis, syntactic ly processedtext, generation :~fintertext, analysisof intermediate-“:nXt , gcnetationof -targ+language text, ,:nd the conversion of target-ianguage?e;xtinto’s form 9uitabR for direct in$erpretaarionby a ha&Maremachine, it is thus postMe to identify six &W-S of extension mechanismsand these are briefly deWbed be?aw. A detrPed survey of extensible languageson the basic of the proposed model will be&en elsewhere 123). The eatenside languagesknown to the author at the time of -Ming {July ! 97 1) are grouped into their exten%ionclasses.FOX languageshave been omitted from tie discussion, nameiyj AIgol68 f27] , ELF [83, BUILD 141,and REL 161,primarily because huff& tient information wagav$Iable about the detaiIs of their implementation, whereas the progsed ciatssifica-
3” “0 8 8 B $,
’
No
6
No
No
’ l
Yes
PL/I subset; cunditional repiacdmeni possible
Yes f
Yes
Extentiontime
.c
Base bnguage
Base language
_
4 Preprockssor
Full &li; conditional r@acement porsiile
--_-_L_.
tion scheme requires a goo@nowledge of the implementation techni’quebefore a bguage can be classified wiflcertainty. vpe&A extensioa Entype-A extension, the extensions to the base language (the augment text) are converted intti constructs off?u during the bxicaI-&iysis sfage of the traristitior: process. This type of extension may be &led “macto extension”. The most common approach is the use of lexical or text macros. Extene sion schemes belonging to this cfassare listed in table I. it is very iikely that other proposals have not found their way into print. Type43extensim; IInthis type of extension, the conversion of the augment text into constructs of & takes place during synta&c analysis of the source text, but before the geperation of the intermediatelanguage text. Type-B extension may thus be called “syntax-extension”. The derived Ianguageis the base ianguage as in the prededing case and this type of exII
N. Solntseff, Classif~don
of ext+wsiFle programming languages
93
ToMe 2 Type-B extensible languages.
Cheatham [ 71 MACRO macros
Any
Base language
Leavenworth jiq smacro macros
Algd 6,4
Base language
Leavfnworth [ 161 fmacro macry
Algol 60
Bast: ianguagls
Standish [ 251 PPL
.PPL :
Yes
Yes
Yes
Syntactic macfes
No conditional replacement
No
Yes
Synutic maci 3s
Extended Algoi 10; condidonal rephcement possible ’
No
Syntactic macros
Extended Algol60;. conditional replacement possible
No
Yes
%? B& language
. .9 .
_-
tension is commonly implemented by means of a preprocessoror tasynt¯o facility. Extension schews belonging t6 this class are listed 111table 2. Oncesag&, it is very likely that there are many more implementations of type-B extension than%re mentioned above, but these have not found their way in- 1 to the literature. Tvpe-c exte&on. Ik type-C extension, the aug-‘ ment text is:converted into a text in the same intermediate language as the base text. The extension takesplace during the generation of the intermediatelanguage text and so may be &led “compile-timeextens&P. Extension schemes belonging to this class are listed in table 3. dn the case ofinterpreted languages, of course, no target code is generated and the intermediate-languagetext ie interpreted by software. It should be noted that the procedure or subroutine facility of high-levellanguagebfalls natually into the proposed classification scheme and may be classified as a type-C extension mechanism. T)pe& extension. In this type of extension, the augment~xt is convertedintu,a-textin an “extended” intermediatelanguage,whereasthe basetext is con-
Yes
,
$0 conditional w placement , _--
YO
,,
, A---
verted into the ‘%ndard” intermediate language. A further conver&c\ Is necessary before a homogeneou’s text in the standard int&$ediate language is produG ?nd the principal exten#on takes place during the fourthstage of the Ganslation proFess, namely, the
stage during which the intermediate-language text is analyzed, btiftbefore the target code is generated. Be- ,’ causeof this, type-l) exte&on may be called “infermed&e&qg.q-e extertsion”. Extension schemes belonging to this class are listed in table 4. In the case of the languages shown in the table, the intermediate tttx’, is a parse tree so that the extension process in-
volvesmanipulation of parse trees. Type-E ex’tension.In the case:of type-E extension, the augment text is converted into a text in the same target language as the base text. It is convenient to consider that the extension takes place during the generation of the target-language texts in distinction to the preceding class in which it takes place during t.he analysis of the inteMlediate=languagetexts. TypeF. extension may thus be called “fotr&Girne exFeMorr*‘. Languageswith an extension meihsnism of this type ’
are listed in table 5.
N. Sohtsefh C’&ts#kationof extemrfblepFmming
94
languages
Tabfe 3 TypeC extensible bur@ages.
Proteus
Proteus
Yes
t Pattern
Yes
inter-
matching; SlWtlCtiC
mediate kilqprage
.mMos and procedures
EPS intermediate language
Yes
Yes
Harrison1131 RALM
Extended LISP 1.5 (XLISP)
XLISP
Spitaer 17Oj c!Ec
CEL
CEL intermediate
Yes
Garw4ck[ 12j GPL
GPL
GPL intermediate
Yes
.
Yes
Yes
Yes
Po&comp& lation syntactic macros
Yes
Yes
Yes
* EPS; condi-
l
No
tional refjlacement possible Yes
Syntatic macros
BALM;
Callson
at intermediate
Yes
Callson built-in dtsc&rotors; macros
GPL; conditional replacement possible
Yes
Extensiol?.
Extension-time capability
E 5.
built-in constructor procedures Yes
Yes
Proteus; conditional replacement posdble
conditioti replacement possible
Table 4 Type-D extensible langua~:s.
M0thOdS
f _it Yes
Computational macros
Ye5
Yes
Yes
Subset ofAPL WLI
Parse tree for PPL
Ye5
Extended Algol 60 (IMP)
PW8e tree for IMP
Yes
l
Yes
Yes
’
Yes
Yes
@
No cond;ttional replacement
No
Tree matching; Cunditionuf replacement only automatic rw can
Nlo
Tree natekin& automatic re+ can
PPL;conditional replacement pea !&la
Yes
Ttee matching; IW, conditional r~ncnt pea rescan under user control slblt
Yes
f
h? Solntseff, Ciuss@catthn of extensible prvgrarnm!ng ianguages
95
Table S Type-E extensible Ianguages. Base language
Extension Methods
MAD
Machine de
Yes
YCS
hlewey (211 LACE
Aw 60
Machine code
Yes
Yei
Solntwff and Yezerski 122,291 ECT
Any
MaChh~
Yes
Arden et al. [l] MAD
s
Ye!
Yes
Yes
code’
7JpdQWensibn. In this type of extension the augmentkxt is convertedinto a text in an “extended” targetlanguage4, whereasthe basetext is converted into a text in the “standard”targetlanguageJZt.The extension processtakesplace duringthe conversionof A?sinto 4 aftertarget-language texts havebeen geaerated, so that th&class of extension my be called ‘VW ” If Es is consideredto be :1 gwkUqp4e e!wentiOil. macroassembler language,then examplesof type-F extension can be found amongsome translator-writirlg systems.As far as is known, thereareno extensi%k languagesmakingUSC of this classof extension mechanism.
References B-W. Alden, BA. Gallar and R.M. Graham, The MAD
definition facility, Comm. ACM 8 ( 1969) 4 32, A. Bayer,
PUTRAN - A gene&tied PL/I macrofacility, in: Proc. Fourth Austr&an Comp. Conf., Adelaide 1 (1969) 291. J.R. Bell, Transformations: The extension facility of Proteus, in 191. RX. Bennett, BUILD - A base for uniform language l
4
Compu tational macros and compiler table changes
Acembler-like pswdocode for specifying code generation
Yes
Ccmputational macros; . compiler table and compiler atruc ture changes Compiler table and compiler structure changes; objectwde file management
C&s on system
NO
procedures tot qecify imrg code generation
High-level lan&age and “text” editor for objet tcode files
Yes
definition, Tech. Report, Computer Horizons Inc., Lincoln, Mass., 1368. ISI P.J. Brown, A survey of macro processors, in: Annual Review in Auto Programming, Vol. 6, Part 2 (1969) Pergamon Press, London, 37. 161V. Thomson Cerf, in: REL, SIGPLAN Notices 4 (Apr. 1969) 23. T.E. Cheatham, The introcIuct:
Platns, N.Y.), Auk. 1968. an extensible language,
c
0
, Wcfo hmction
extension of compifcr
system user extensible Proc. AFWS 1968 FJCC, Vol. 33 i Rut 2, mid A. Yezerski, ECT - An extensiblewn-
&or system July 1971, Inform. Proc.
Letters 1 (1972) 97. (231 NI Sohrtscff and A. Yezerski, A look at programmingwge exten;.ibili;y (in preparation). [24) i.M. Spitzen, The design and implementation of a conversational extensible language, Harvard University, Cambridge, brlas~chusetts (May. 19tO). 1251 T.A. Standish, Some featuresof PPL, A polymorphuc ’ programming language, in [ 91. [26j T.A. Starr&h, Some compiler-compiler techniquea. for use in extensible Languages,in (91. [ 271 Van Wijngaarden (rtrd,)Report on the, Algorithmic Eanguage .ALGOL 68, Report MR iC 1.DMothumatisch Centrum, Amsterdam, Second Printing (October 1969). (281 P. Wegner, Theories of ilemanticq Tech. Report No. 69-10. Ceutre for Computer 69ndInfo, Scituwy &own Univ. Providence, R.I. (Septen$er 3969). 1291 A. Yezenki. Extensible Contracttble T&slatcu$, L:octom1 Dissertatiorn, The Univ. of New South Wales; Sydney, N.S.W. (March 1971).
N. SOLNTSEFF Lkpwtment
tf
Applied MU *hemarks, MiMaster
Universitv, ;/amilton,
Ontario, Canada
Received 30 September 197 I
exten$ble languages programming languagesclassification
The need for a classification scheme for extensible prograrr.ming lank*lages has become apparent because of their growing numbers. The formal methods used to describe programming languages [28] have not addressed themselves to the problem osextensibility largely, it seems, because in Wegner’s words “Mathe-’ maticians regarda defiiition as a form of abbrevia- l tion \4kh sometimes provides useful insights by associating a name with an intuitively importandconcept, but which does not add vy new content $I the theory”. It is thus very easy to dismiss the problem of definition as being trivial since a defined term can be everywhere replaced by the aerms used to define it, so that definitio,)ris considered merely as a shorthand for reducing the length of texts. The author has been able tb find only t#o papers giving a formal description of extensiblg langkges [ 10, 171. These papers describe only one approach to l language extensiiility~ In the first, Letichevskii adopts a set-theoretic approach to the description of macroextensible languages, while the second gives a description of the PL.0 compile time facility [ 141 in the Vienna Defmition Language [ 181. AJtiough the early proposals for programrning4angu~~eextension [ 7, 16, 19] were based on the use of macro processors [S] , ’ some of the more recent proposals (for example, see 19] ) involve mechanisms which are difficult to fit into *The work described here was performed while the author was in the Department of Electrical Engineering, University of Colorado. +Revised version of paper presented at the Internationlll Symposium of Extensible Languages,Grenoble,@terr.ber 3-5, 1971.
macro
formal model
translation extension mechanism
this classification so that a broader framework is req;lired. A clas,’SIfrcat ion izheme which fias helped the author the introduce riozje order intc the existing and proposed extensible languages is given below. In the absence of a formal model of language extensibility, it is necessary to adopt a qualitative approach and to aim at the construction of a model suitable for the comparison and evaluation of implemented and proposed extensible languages. A convenient framework is the translation process by which i: “source” program is converted into a “target” program capable of being run on 3 hardware machiru . A program in an extensible language consists of a combination of a base texf B in the base language&$ (the language bt)i extended) and an arrgmeuttexf A expressed in term7- of constructs which Jre not part of &, but which have been suitably defined. The text A may be considered to be in an augment language 4$. A and B together form a text E in an extetrded far?guageSe. The language into which L!a is converted by an extonsion may be called the derived Imguage. The definitions form a text D which may be a part of either A or B. This second augment D is a text in a defirzitiorthguage Gd which. in genera!. will be distinct from Pa and L?b. If, however. ~2~C 2,. then the base language can be terme,d to be sc!j:exterlditlg.It should be noted that statements in .@aarc in the INture of declarations since t!iey do n&t give rise to executable code, although they zffect the cou:sr;- of the translation process once they are encountered and thus affect the form of the target program. ’ nle classification of the extension mecl:ilnisms CM be made on the basis of the stage of the tra&tiulI
N. Solntseff) Ck&fication of exteatsibk prvqamming hmguages
32
_
Table i Type-A tx tensibk languages. __---__--__ -0
_~-----~----_-.--Derived Base language language
Mcllroy [ 191
2s ze 33 2s v3 I
.-p-y.
- __.-- -_v -
-
“2 4% $2 3% rfi & i3 ar::
Any
CZ 22 23 k”3w
&Yes
Yes
Base language
Yes
Yes
RJ lang&e
Yes *
Extension Methods
Yes
Text macros
High level with conditional replacement
Text macros
No co ditionalTepiacenient
Semi-@ntactic macros
No conditional replaQement
14
-e
_
Yes
” &es
..
which the definition o,i an extension is e there are six identifiable stages in the ocess, namely, lefticalanalysis, syntactic ly processedtext, generation :~fintertext, analysisof intermediate-“:nXt , gcnetationof -targ+language text, ,:nd the conversion of target-ianguage?e;xtinto’s form 9uitabR for direct in$erpretaarionby a ha&Maremachine, it is thus postMe to identify six &W-S of extension mechanismsand these are briefly deWbed be?aw. A detrPed survey of extensible languageson the basic of the proposed model will be&en elsewhere 123). The eatenside languagesknown to the author at the time of -Ming {July ! 97 1) are grouped into their exten%ionclasses.FOX languageshave been omitted from tie discussion, nameiyj AIgol68 f27] , ELF [83, BUILD 141,and REL 161,primarily because huff& tient information wagav$Iable about the detaiIs of their implementation, whereas the progsed ciatssifica-
3” “0 8 8 B $,
’
No
6
No
No
’ l
Yes
PL/I subset; cunditional repiacdmeni possible
Yes f
Yes
Extentiontime
.c
Base bnguage
Base language
_
4 Preprockssor
Full &li; conditional r@acement porsiile
--_-_L_.
tion scheme requires a goo@nowledge of the implementation techni’quebefore a bguage can be classified wiflcertainty. vpe&A extensioa Entype-A extension, the extensions to the base language (the augment text) are converted intti constructs off?u during the bxicaI-&iysis sfage of the traristitior: process. This type of extension may be &led “macto extension”. The most common approach is the use of lexical or text macros. Extene sion schemes belonging to this cfassare listed in table I. it is very iikely that other proposals have not found their way into print. Type43extensim; IInthis type of extension, the conversion of the augment text into constructs of & takes place during synta&c analysis of the source text, but before the geperation of the intermediatelanguage text. Type-B extension may thus be called “syntax-extension”. The derived Ianguageis the base ianguage as in the prededing case and this type of exII
N. Solntseff, Classif~don
of ext+wsiFle programming languages
93
ToMe 2 Type-B extensible languages.
Cheatham [ 71 MACRO macros
Any
Base language
Leavenworth jiq smacro macros
Algd 6,4
Base language
Leavfnworth [ 161 fmacro macry
Algol 60
Bast: ianguagls
Standish [ 251 PPL
.PPL :
Yes
Yes
Yes
Syntactic macfes
No conditional replacement
No
Yes
Synutic maci 3s
Extended Algoi 10; condidonal rephcement possible ’
No
Syntactic macros
Extended Algol60;. conditional replacement possible
No
Yes
%? B& language
. .9 .
_-
tension is commonly implemented by means of a preprocessoror tasynt¯o facility. Extension schews belonging t6 this class are listed 111table 2. Oncesag&, it is very likely that there are many more implementations of type-B extension than%re mentioned above, but these have not found their way in- 1 to the literature. Tvpe-c exte&on. Ik type-C extension, the aug-‘ ment text is:converted into a text in the same intermediate language as the base text. The extension takesplace during the generation of the intermediatelanguage text and so may be &led “compile-timeextens&P. Extension schemes belonging to this class are listed in table 3. dn the case ofinterpreted languages, of course, no target code is generated and the intermediate-languagetext ie interpreted by software. It should be noted that the procedure or subroutine facility of high-levellanguagebfalls natually into the proposed classification scheme and may be classified as a type-C extension mechanism. T)pe& extension. In this type of extension, the augment~xt is convertedintu,a-textin an “extended” intermediatelanguage,whereasthe basetext is con-
Yes
,
$0 conditional w placement , _--
YO
,,
, A---
verted into the ‘%ndard” intermediate language. A further conver&c\ Is necessary before a homogeneou’s text in the standard int&$ediate language is produG ?nd the principal exten#on takes place during the fourthstage of the Ganslation proFess, namely, the
stage during which the intermediate-language text is analyzed, btiftbefore the target code is generated. Be- ,’ causeof this, type-l) exte&on may be called “infermed&e&qg.q-e extertsion”. Extension schemes belonging to this class are listed in table 4. In the case of the languages shown in the table, the intermediate tttx’, is a parse tree so that the extension process in-
volvesmanipulation of parse trees. Type-E ex’tension.In the case:of type-E extension, the augment text is converted into a text in the same target language as the base text. It is convenient to consider that the extension takes place during the generation of the target-language texts in distinction to the preceding class in which it takes place during t.he analysis of the inteMlediate=languagetexts. TypeF. extension may thus be called “fotr&Girne exFeMorr*‘. Languageswith an extension meihsnism of this type ’
are listed in table 5.
N. Sohtsefh C’&ts#kationof extemrfblepFmming
94
languages
Tabfe 3 TypeC extensible bur@ages.
Proteus
Proteus
Yes
t Pattern
Yes
inter-
matching; SlWtlCtiC
mediate kilqprage
.mMos and procedures
EPS intermediate language
Yes
Yes
Harrison1131 RALM
Extended LISP 1.5 (XLISP)
XLISP
Spitaer 17Oj c!Ec
CEL
CEL intermediate
Yes
Garw4ck[ 12j GPL
GPL
GPL intermediate
Yes
.
Yes
Yes
Yes
Po&comp& lation syntactic macros
Yes
Yes
Yes
* EPS; condi-
l
No
tional refjlacement possible Yes
Syntatic macros
BALM;
Callson
at intermediate
Yes
Callson built-in dtsc&rotors; macros
GPL; conditional replacement possible
Yes
Extensiol?.
Extension-time capability
E 5.
built-in constructor procedures Yes
Yes
Proteus; conditional replacement posdble
conditioti replacement possible
Table 4 Type-D extensible langua~:s.
M0thOdS
f _it Yes
Computational macros
Ye5
Yes
Yes
Subset ofAPL WLI
Parse tree for PPL
Ye5
Extended Algol 60 (IMP)
PW8e tree for IMP
Yes
l
Yes
Yes
’
Yes
Yes
@
No cond;ttional replacement
No
Tree matching; Cunditionuf replacement only automatic rw can
Nlo
Tree natekin& automatic re+ can
PPL;conditional replacement pea !&la
Yes
Ttee matching; IW, conditional r~ncnt pea rescan under user control slblt
Yes
f
h? Solntseff, Ciuss@catthn of extensible prvgrarnm!ng ianguages
95
Table S Type-E extensible Ianguages. Base language
Extension Methods
MAD
Machine de
Yes
YCS
hlewey (211 LACE
Aw 60
Machine code
Yes
Yei
Solntwff and Yezerski 122,291 ECT
Any
MaChh~
Yes
Arden et al. [l] MAD
s
Ye!
Yes
Yes
code’
7JpdQWensibn. In this type of extension the augmentkxt is convertedinto a text in an “extended” targetlanguage4, whereasthe basetext is converted into a text in the “standard”targetlanguageJZt.The extension processtakesplace duringthe conversionof A?sinto 4 aftertarget-language texts havebeen geaerated, so that th&class of extension my be called ‘VW ” If Es is consideredto be :1 gwkUqp4e e!wentiOil. macroassembler language,then examplesof type-F extension can be found amongsome translator-writirlg systems.As far as is known, thereareno extensi%k languagesmakingUSC of this classof extension mechanism.
References B-W. Alden, BA. Gallar and R.M. Graham, The MAD
definition facility, Comm. ACM 8 ( 1969) 4 32, A. Bayer,
PUTRAN - A gene&tied PL/I macrofacility, in: Proc. Fourth Austr&an Comp. Conf., Adelaide 1 (1969) 291. J.R. Bell, Transformations: The extension facility of Proteus, in 191. RX. Bennett, BUILD - A base for uniform language l
4
Compu tational macros and compiler table changes
Acembler-like pswdocode for specifying code generation
Yes
Ccmputational macros; . compiler table and compiler atruc ture changes Compiler table and compiler structure changes; objectwde file management
C&s on system
NO
procedures tot qecify imrg code generation
High-level lan&age and “text” editor for objet tcode files
Yes
definition, Tech. Report, Computer Horizons Inc., Lincoln, Mass., 1368. ISI P.J. Brown, A survey of macro processors, in: Annual Review in Auto Programming, Vol. 6, Part 2 (1969) Pergamon Press, London, 37. 161V. Thomson Cerf, in: REL, SIGPLAN Notices 4 (Apr. 1969) 23. T.E. Cheatham, The introcIuct:
Platns, N.Y.), Auk. 1968. an extensible language,
c
0
, Wcfo hmction
extension of compifcr
system user extensible Proc. AFWS 1968 FJCC, Vol. 33 i Rut 2, mid A. Yezerski, ECT - An extensiblewn-
&or system July 1971, Inform. Proc.
Letters 1 (1972) 97. (231 NI Sohrtscff and A. Yezerski, A look at programmingwge exten;.ibili;y (in preparation). [24) i.M. Spitzen, The design and implementation of a conversational extensible language, Harvard University, Cambridge, brlas~chusetts (May. 19tO). 1251 T.A. Standish, Some featuresof PPL, A polymorphuc ’ programming language, in [ 91. [26j T.A. Starr&h, Some compiler-compiler techniquea. for use in extensible Languages,in (91. [ 271 Van Wijngaarden (rtrd,)Report on the, Algorithmic Eanguage .ALGOL 68, Report MR iC 1.DMothumatisch Centrum, Amsterdam, Second Printing (October 1969). (281 P. Wegner, Theories of ilemanticq Tech. Report No. 69-10. Ceutre for Computer 69ndInfo, Scituwy &own Univ. Providence, R.I. (Septen$er 3969). 1291 A. Yezenki. Extensible Contracttble T&slatcu$, L:octom1 Dissertatiorn, The Univ. of New South Wales; Sydney, N.S.W. (March 1971).