Cool. The last time I talked with Ter about this, his idea was to turn the code stream into a set of small abstract instructions which a code generator could walk, transform or otherwise mess with at certain points, and then use that generate code. I am not sure how far along he is with that, but I am not sure that functional languages were considered particularly. I am sure he will comment before too long.
Jim > -----Original Message----- > From: antlr-dev-boun...@antlr.org [mailto:antlr-dev-boun...@antlr.org] > On Behalf Of Mark Wright > Sent: Tuesday, January 18, 2011 4:24 AM > To: antlr-dev@antlr.org > Subject: [antlr-dev] Haskell, LISP, other weird stuff > > Hi, > > Since ANTLR v4 is in development, I was wondering if there were any > thoughts on making it possible to hook into the code generation earlier > in order to be able to add support for weird functional languages such > as Haskell, Lisp, Scheme, Racket, etc. There were some earlier > thoughts on this which I copied below. > > I did have a look earlier at the feasibility of writing an ANTLR > runtime target for Haskell. This seemed difficult for ANTLR v3, I > could not see how to easily hook into code generation earlier. Since > ANTLR v3 does not seem to have support for weird functional language > targets, the string templates ended up being designed for imperative > languages. > > As a workaround for ANTLR v3, I have written a Haskell binding to the > ANTLR v3.2 C runtime library: > > http://hackage.haskell.org/package/antlrc > https://github.com/markwright/antlrc > > Thanks, Mark > > http://antlr.org/blog/antlr3/codegen.html > > November 18, 2003 > > A primary goal is easy code gen for a variety of languages. This > necessarily requires a multi-phase translation approach so people can > jump in wherever they want in the code gen process. Here is what I'm > thinking > > grammar -> NFA -> NFA+DFA -> ParseLang -> NIL -> C, C++, Java, Perl, > ... > | | > | |-------------> Perl, ... > | > |-------------------------> LISP, other weird > stuff > > where ParseLang is some antlr parser intermediate form and NIL is some > "neutral imperative language". NIL (just a random name now) would also > be presumably the ANTLR grammar action language as well. Given a NIL > translator to language L, you could translate actions as well as > generate parses in L. > > If your language is sort of an imperative language, but perhaps with > higher level recognition capabilities, you would probably generate code > from the ParseLang stage as imperative method calls etc.. would be too > low level. > > If you have a truly non-imperative language such as LISP or other > functional language, you would branch off the grammar representation > containing the lookahead analysis: NFA+DFA stage. > > ParseLang would look like the AST for a high-level language. The reason > I don't go straight to NIL or Java for example is that ANTLR has to > break apart some alternative lists due to lookahead and to insert tree > actions. There should be an easy way to dump this from the internal > grammar NFA representation. From there, it's a simple matter of > translating to a imperative-language neutral form and then to final > instruction selection. > > ParseLang would also be a convenient place to interpret ANTLR for > prototyping. > > As an example, consider > s : a[42] | Z ; > a[int i] : A B | C ; > > The ParseLang tree might be > RULE > | > s -- ARGS -- SELECT > | > CASE ---------------------------- CASE > | | > SET{A,C} -- SLIST TOKEN(Z) -- SLIST > | | > INVOKE MATCH > | | > a -- ARGS Z > | > INT(42) > > Note that there would be no infrastrutcure variable definition like AST > pointers and labels etc... That would only appear in an actual output > language or in the NIL format. > > >From ParseLang you would translate the SELECT to a SWITCH in a NIL > >format > etc... Using translation templates, you could even go straight to a > programming language like this: > > #(SELECT #(CASE expr slist)) ==> "switch (LA(1)) <cases:{"case <expr> : > <slist>; break;"> }" > > #(INVOKE ID #(ARGS (arg)+)) => "<ID>(<arg>);" > > Or, more likely, these output templates could be used as a convenient > way to generate NIL trees by running the NIL parser over the output > templates. This lets you use text as humans like to read as the output > of a translation phase while still getting out a trees. :) Cute. From > the NIL tree you could translate to any imperative language easily. > > I'm getting more and more fond of the notion that ANTLR will have a > simple standard imperative language as it's action language format. > This way all grammars are portable to all languages even with symbol > table actions etc.... :) Woohoo! > _______________________________________________ > antlr-dev mailing list > antlr-dev@antlr.org > http://www.antlr.org/mailman/listinfo/antlr-dev _______________________________________________ antlr-dev mailing list antlr-dev@antlr.org http://www.antlr.org/mailman/listinfo/antlr-dev
