[antlr-interest] Parsing Lisp into C++

Loring Craymer lgcraymer at yahoo.com
Mon Sep 28 02:54:09 PDT 2009


If you really want to re-invent the wheel, that's your business.  Given that Lisp is a prefix functional language (minimal syntax) and that all extensions (and the interpreter itself) are written in Lisp, it is unlikely to be difficult to get your code to compile with a commercial Lisp compiler capable of generating standalone executables.  There has been quite a bit of research on optimizing compilers for functional languages (particularly Lisp), and very little likelihood that you can write a more efficient translator than you can buy.

--Loring





----- Original Message ----
> From: Richard Lewis <Richard.Lewis at razor-risk.com>
> To: Loring Craymer <lgcraymer at yahoo.com>; antlr-interest at antlr.org
> Sent: Monday, September 28, 2009 1:53:41 AM
> Subject: RE: [antlr-interest] Parsing Lisp into C++
> 
> 
> This is not  an intellectual exercise or a homework assignment. The Lisp in 
> question is a peculiar dialect of CLOS developed for our clients to be able to 
> embed scripting behavior in our application suite. The interpreter has been 
> tweaked to the point of which we can no longer squeeze out any more performance 
> gains. There are 10's of thousands of lines of code distributed amongst many 
> clients so changing the language in any way is not an option. 
> 
> So the next step is to have it compiled natively. 
> 
> The requirements  are:
> 
> 1. Lexical analyser and parser needs to support our dialect of lisp
> 2. The runtime library needs to be multithreaded and flexible (thinking native 
> LLVM or OpenCL)
> 3. Has to be compiled into native machine code (i.e. can't run in a virtual 
> machine)
> 
> My question was one of style with using Antlr... Is it better to muddy the 
> parser grammar with a single pass or split the AST creation into 2 passes?
> 
> -Richard
> 
> -----Original Message-----
> From: Loring Craymer [mailto:lgcraymer at yahoo.com]
> Sent: Mon 9/28/2009 3:49 PM
> To: Richard Lewis; antlr-interest at antlr.org
> Subject: Re: [antlr-interest] Parsing Lisp into C++
> 
> This is a case where I have to ask "why".  The typical Lisp compiler (not 
> interpreter) is a Lisp to C translator with some additional glue.  You can 
> probably even find support for translating CLOS to C++ if you look around.
> 
> --Loring
> 
> 
> 
> >
> >From: Richard Lewis 
> >To: antlr-interest at antlr.org
> >Sent: Sunday, September 27, 2009 6:32:19 PM
> >Subject: [antlr-interest] Parsing Lisp into C++
> >
> > >
> >
> >
> >>
> >I've started looking into translating a large amount of
> >legacy Lisp code into C++ using Antlr. I put together a simple grammar that
> >generates an AST. My question is: Where is the best place to attach semantic  
> information?
> >It seems to me that I should have a 2 pass parser, starting with the AST as
> >shown below and then making  an additional pass to generate another AST
> >that contains semantics. Unfortunately I'm not that familiar with Lisp but it
> >seems to be difficult to parse in a single pass without resorting to an ugly
> >grammar definition since everything in Lisp seems to be an expression of some
> >sort.  This is ironic since Lisp already seems to be "parsed". 
> > 
> >Input:
> > 
> >(defun foo (x y) (progn (+ x 1) (+ y 1)))
> > 
> >Grammar:
> > 
> >program: (sexpr)* -> ^(PROGRAM sexpr*);
> >sexpr: QT?(list|atom) ;
> >list:      '(' ')'   |
> >'(' members ')'  -> ^(LIST members);
> >members: (sexpr)+;
> >atom: OPERATOR | ID | num | STRING ;
> >num       : (n=INT|n=FLOAT)
> >-> ^(NUM $n);
> > 
> >AST Output:
> > 
> >PROGRAM
> >     LIST
> >           defun
> >           foo
> >           LIST
> >                x
> >                y
> >           LIST
> >                progn
> >                LIST
> >                     +
> >                     x
> >                     1
> >                LIST
> >                     +
> >                     y
> >                     1
> > 
> >Desired Output:
> > 
> >PROGRAM
> >     FUNCTION
> >           foo
> >           ARGS
> >                x
> >                y
> >           BLOCK
> >                +
> >                     x
> >                     1
> >                +
> >
> >                     y
> >                     1
> > 



      


More information about the antlr-interest mailing list