Re: Implementation Language Choice

Lex Spoon <lex@cc.gatech.edu>
26 Feb 2004 01:09:45 -0500

          From comp.compilers

Related articles
Implementation Language Choice kevin@albrecht.net (Kevin Albrecht) (2004-02-12)
Re: Implementation Language Choice kenrose@tfb.com (Ken Rose) (2004-02-13)
Re: Implementation Language Choice wienczny@web.de (Stephan Wienczny) (2004-02-13)
Re: Implementation Language Choice basile-news@starynkevitch.net (Basile Starynkevitch \[news\]) (2004-02-13)
Re: Implementation Language Choice joachim.durchholz@web.de (Joachim Durchholz) (2004-02-13)
Re: Implementation Language Choice kevin@albrecht.net (Kevin Albrecht) (2004-02-13)
Re: Implementation Language Choice lex@cc.gatech.edu (Lex Spoon) (2004-02-26)
Re: Implementation Language Choice joachim.durchholz@web.de (Joachim Durchholz) (2004-02-26)
Re: Implementation Language Choice gdr@integrable-solutions.net (Gabriel Dos Reis) (2004-02-27)
Re: Implementation Language Choice joachim.durchholz@web.de (Joachim Durchholz) (2004-03-02)
Re: Implementation Language Choice la@iki.fi (Lauri Alanko) (2004-03-02)
Re: Implementation Language Choice lex@cc.gatech.edu (Lex Spoon) (2004-03-02)
Re: Implementation Language Choice torbenm@diku.dk (2004-03-06)
[4 later articles]
| List of all articles for this month |
From: Lex Spoon <lex@cc.gatech.edu>
Newsgroups: comp.compilers
Date: 26 Feb 2004 01:09:45 -0500
Organization: Georgia Institute of Technology
References: 04-02-109 04-02-131
Keywords: functional
Posted-Date: 26 Feb 2004 01:09:45 EST

Joachim Durchholz <joachim.durchholz@web.de> writes:
> Kevin Albrecht wrote:
>
>> What languages have others found useful as implementation
>> languages?
>
> Functional languages have been reported to be exceedingly strong in this
> area. You essentially define a few helper functions, then the parser is
> a simple transliteration of the grammar rules. (The keywords to google
> for are "parsing combinators".)
> In particular, it seems to be easy to attach different things to the
> parsers (for "things" say prettyprinters, code transformers, compilers,
> and whatnot).


Additionally, functional languages seem effective for the later stages
of a compiler. Most compilers can be written as a long series of
transformations of representations starting with source code and
ending with binary code; each one of these representations can usually
be represented as tree structures or as lists of tree structures.
Functional languages are *terrific* at converting one list of trees
into another list of trees.


The feature that is especially nice is the pattern-matching switch
statement that most functional languages include. It lets you break
encapsulation and dig multiple levels into the structure of a tree, so
that, say, a move from a register to a register, is handled in a
separate branch from a move from a memory location to a memory
location that is specified directly in a register.


But also garbage collection is a key advantage. As well, it is nice
to have higher-order functions themselves can prove useful; you can
write little routines that will wander over a tree structure and apply
a function you specify. But many languages have these things
nowadays. The relatively unusual feature is the deeply reaching
switch statements.


I sometimes wonder if functional language designers know about any
programs *other* than compilers. :) However you take this, it is
clear that the ML family has proven a very effective implementation
language for compilers.




-Lex


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.