[antlr-interest] Code generation advice

[Eric]

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
>