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
