[antlr-interest] Code generation advice

Wed Jun 20 13:34:42 PDT 2012

Eric,
  I think you've pretty much summed it up.  :)  The reason I thought
to yet use ANTLR is, e.g. if this is done as a custom ANTLR code
target, I should get a lot of stuff done for me for free with regard
to processing the mother, or meta, grammar into a model of a grammar,
e.g. org.antlr.v4.tool.Grammar.

I still have to get through your other references telling me just a
few of the many things I don't know.  ;)

Matt

On Wed, Jun 20, 2012 at 3:16 PM, Eric <researcher0x00 at gmail.com> wrote:
> Hi Matt,
>
> Here is a summary of what I understand that you want. Please correct me
> where I am wrong.
>
> You want to create a grammar, the mother grammar for lack of something that
> would be confusing, for creating other DSL grammars.
>
> As an example the mother grammar would be ANTLR or some variant of ANTLR,
> and the DSL grammar would be any grammar the user is intending to create.
> Let's say the DSL grammar is for DOT files, yes I know there really is a DOT
> file grammar created by ANTLR.
>
> So using your mother grammar, the user would define the DOT grammar. Now
> comes the big difference; instead of using the DOT grammar as an input to
> ANTLR, you would use the DOT grammar to generate Java Interfaces that can be
> called by the end program. I am not sure of what happens between the call to
> the Java interface and the output of the call, but the point is that you are
> not using ANTLR, but going straight from a call based on grammar rule as a
> Java interface to some ouput such as an AST.
>
> Eric
>
>
>
>
> On Wed, Jun 20, 2012 at 3:54 PM, Eric <researcher0x00 at gmail.com> wrote:
>>
>> Hi Matt,
>>
>> It is now making much more sense.
>>
>> How do you plan on ensuring the grammar is not ambiguious?
>> Will the grammar have to conform to one of the Chomsky hierarchies?  See:
>> http://en.wikipedia.org/wiki/Chomsky_hierarchy
>> It sounds like when you are done you be recreating PROLOG's Definite
>> Clause Grammar.
>> See: http://en.wikipedia.org/wiki/Definite_clause_grammar
>>
>> Eric
>>
>> On Wed, Jun 20, 2012 at 3:44 PM, Matt Benson <gudnabrsam at gmail.com> wrote:
>>>
>>> Hi, Scott--and thanks for ANTLREclipse, which (never having moved past
>>> v2) I still use.  ;)  Actually, embedded in my original email was the
>>> fact that I have looked at xtext and making it do what I'm looking for
>>> is at least an endeavor whose HOWTO is non-obvious.  AFAICT, its focus
>>> is on parsing a DSL into a Java model:  well and good, but I know how
>>> to do that with ANTLR.  Xtext might well make this job easier, but in
>>> my case, I want more or less to bypass the idea of parsing a DSL and
>>> simply use the same meta-grammar to describe an embedded DSL whose
>>> rules are actually invoked as Java methods.  Possibly xtext *can* do
>>> this, but so far its documentation is quite obtuse to me, and I have
>>> yet to see anything in its examples that suggests that it would give
>>> me a leg up on this particular task.
>>>
>>> @Eric:  your question is answered ;)
>>>
>>> Regards,
>>> Matt
>>>
>>> On Wed, Jun 20, 2012 at 2:31 PM, Scott Stanchfield <scott at javadude.com>
>>> wrote:
>>> > Have you taken a look at xtext ( http://www.eclipse.org/Xtext/) It uses
>>> > a
>>> > grammar similar to antlr to generate model interfaces/classes, a
>>> > syntax-highlighting editor (optional, but very useful), persistence
>>> > manager
>>> > and other doodads. Under the covers it uses antlr to do the actual
>>> > parsing.
>>> >
>>> > xtext is intended for DSL definition and is rather mature, too.
>>> >
>>> > As a really short example (from the xtext site):
>>> >
>>> > grammar org.xtext.example.mydsl.MyDsl
>>> >     with org.eclipse.xtext.common.Terminals
>>> >
>>> > generate myDsl "http://www.xtext.org/example/mydsl/MyDsl"
>>> >
>>> > Model:
>>> >     greetings+=Greeting*;
>>> >
>>> > Greeting:
>>> >     'Hello' name=ID '!';
>>> >
>>> > would generate a Model class that has a property greetings which is a
>>> > list
>>> > of Greeting instances, and a Greeting class that has a name property.
>>> >
>>> > I don't know if it fits exactly what you're looking for, but it's worth
>>> > taking a look.
>>> > -- Scott
>>> >
>>> > ----------------------------------------
>>> > Scott Stanchfield
>>> > http://javadude.com
>>> >
>>> >
>>> >
>>> > On Wed, Jun 20, 2012 at 2:49 PM, Matt Benson <gudnabrsam at gmail.com>
>>> > wrote:
>>> >>
>>> >> 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
>>> >> >
>>> >> >
>>> >>
>>> >> List: http://www.antlr.org/mailman/listinfo/antlr-interest
>>> >> Unsubscribe:
>>> >> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>>> >
>>> >
>>>
>>> List: http://www.antlr.org/mailman/listinfo/antlr-interest
>>> Unsubscribe:
>>> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>>
>>
>