[antlr-interest] Code generation advice

Matt Benson gudnabrsam at gmail.com
Wed Jun 20 11:49:35 PDT 2012


What I want to do is make it easier to write an EDSL by having it
specified like any other grammar, generating Java interfaces to
represent the grammar's various rules, as well as basic
implementations of these, which I expect will accumulate "tokens"
extracted from method arguments specified in fluent fashion.  In fact,
spelling it out here makes it sound as though it might be just as
reasonable for the end result of a series of calls upon the
implementation of this EDSL interface to create a (parse?) tree, which
could then be walked to resolve the final result of such a series of
method invocations.  This would have the benefit that such a tree
walker (parse, AST, what-have-you) would be equally applicable to a
tree generated from a "normal" ANTLR-generated Java Parser
implementation.

Is that more clear?

Thanks for your interest,
Matt

On Wed, Jun 20, 2012 at 1:14 PM, Eric <researcher0x00 at gmail.com> wrote:
> Ok, I'm curious as to what you are trying to do. It sounds like something I
> once tinkered with but since I did not understand your exact goal I could be
> totally wrong.
>
> The only part that I understood as part of the goal was "generation of Java
> interfaces from EBNF-style grammars". Are you trying to generate Java
> interfaces from a grammar for other languages or interface languages such as
> C++, CORBA, etc.?
>
> Eric
>
>
>
> On Wed, Jun 20, 2012 at 12:08 PM, Matt Benson <gudnabrsam at gmail.com> wrote:
>>
>> Hi all,
>>  In the Java ecosystem embedded DSLs have become increasingly popular
>> over the past several years.  In my opinion the primary drawback to
>> these is the painful task of their creation.  For this reason I want
>> to experiment with the generation of Java interfaces from EBNF-style
>> grammars to see what I can accomplish, in true Dr. Terence Parr "why
>> program by hand in 5 days..." fashion.  I have explored, for example,
>> xtext, but the process of going from its meta-grammar to EDSL code is
>> non-obvious.  I'm open to other suggestions if anyone has any, but in
>> the meantime I'm looking at ANTLR 4 and/or 3-based approaches.  It
>> would seem most appropriate to use the ANTLR 4 meta-grammar, from
>> which point I would seem to have the following options:
>>
>> * Implement a custom code generation target for ANTLR 4
>> * Use ANTLRMorph with the ANTLR 3-based ANTLR 4 meta-grammar
>>
>> It might well be the case that these differ only in the manner in
>> which the output stringtemplates are provided.  Does anyone have any
>> opinions on which approach is to be preferred?  Failing that, I am
>> willing to entertain aspersions cast on, or less likely, advocations
>> in favor of, my sanity in conceiving this endeavor.
>>
>> Thanks in advance for any input,
>> Matt
>>
>> List: http://www.antlr.org/mailman/listinfo/antlr-interest
>> Unsubscribe:
>> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>
>


More information about the antlr-interest mailing list