[antlr-interest] Can't create AST Node?

[Tiller, Michael (M.M.)]

Well, when I'm done I'm going to try and convince the powers that be
here to allow me to release the code to try and promote the use of the
language by vendors, suppliers, etc.  We'll see if that flies.

I doubt I'm going to have anything very interesting to show (from a Java
perspective) because this is an extremely low priority to my management
so I suspect it will very quickly be on the very back burner (before I
get something useful).

With regards to ANTLR 'fest, I'm happy to share my experiences and ideas
(even if I don't have any actual code worth/able to share).  I don't
doubt the value of tree parsers in many circumstances and, to be honest,
I don't know if there is really a barrier to enjoying the best of both
worlds.  I'm just at the point where I'm tired of wrestling the het-AST
support.  With time, ANTLR may very well support the best of both
worlds.

I think there may be some interesting possibilities for using
introspection on the Java side to deal with tree walking.  For example,
do you really need first child, next sibling, etc when you can get a
complete inventory of fields?!?  I mean why not make a tree walker that
works with native objects rather than having to create special AST
nodes?  Couldn't you just use java.reflect + instanceof (I'm no Java
expert and I'm not sure how "portable" it would be).  That way you could
both walk existing Java classes and potentially create new ones as you
went.  The idea is AST=java.Object, children=java.reflect.Fields and you
just use/create native Java objects.  No special base classes (for
example).  Perhaps the overhead would be too much?!?  Just a thought.

One last comment, I suspect that it might be useful to provide automatic
"visitor generation" for people where visitors seem more attractive (ala
SableCC?).

--
Mike

> -----Original Message-----
> From: Monty Zukowski [mailto:monty at codetransform.com]
> Sent: Thursday, July 08, 2004 4:03 PM
> To: antlr-interest at yahoogroups.com
> Cc: Monty Zukowski
> Subject: Re: [antlr-interest] Can't create AST Node?
> 
> Yeah, it's all coming back to me now.  I remember reading the paper
> before, I think.  I'm glad to hear you are now targeting Java, just
> because that's easier for me to understand.  At some point I'd really
> like to see the code to this.  This would make an excellent project to
> analyze in preparation for the ANTLR 'fest, which seems to be coming
in
> October according to the latest rumors.  It's a wacky language, rather
> dense, declarative instead of interpreted, and you're doing source
code
> analysis, which is cool.  From your description you need random
access,
> some graph processing type of functionality, as well as typical tree
> walker stuff.
> 
> Any chance I could have a deeper look?  I'd be happy to sign an NDA if
> necessary.  You can contact me privately if you like through my
> website.
> 
> Monty
> 
> 
> ANTLR & Java Consultant -- http://www.codetransform.com
> ANSI C/GCC transformation toolkit --
> http://www.codetransform.com/gcc.html
> Embrace the Decay -- http://www.codetransform.com/EmbraceDecay.html
> 
> On Jul 8, 2004, at 12:34 PM, Tiller, Michael ((M.M.)) wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: Monty Zukowski [mailto:monty at codetransform.com]
> >> Subject: Re: [antlr-interest] Can't create AST Node?
> >>
> >> On Jul 8, 2004, at 10:52 AM, Tiller, Michael ((M.M.)) wrote:
> >>
> >> Still not sure what you are trying to do :)
> >
> > Well, as I've said many times, I'm no expert in compiler
development.
> > The language I'm working with is Modelica (http://www.modelica.org,
> > which includes the language specification, i.e. grammar +
semantics).
> >
> > I'm trying to do some very specific things but protecting for others
as
> > well.  The main goal of my work is in code metrics.  So I'm
interested
> > in analyzing source code.  But Modelica is more of a declarative
> > language rather than an imperative or procedural language.  This is
> > important because Modelica involves an "instantiation" process (you
> > might also call it an elaboration process) which is the tricky part
> > (from my perspective).  There are a couple of papers on the Modelica
> > site from the most recent conference that discuss language tools
> > (including a paper I wrote about what I'm doing).
> >
> >> Yeah, but that can get cumbersome at the object level with
recursion
> >> and alternatives.  It depends a great deal on the complexity of the
> >> language.
> >
> > Sure and I'm completely willing to accept that I'm just being stupid
> > and
> > not recognizing the value of the tree parsers.  It's a bit of a
> > learning
> > experience.  What I can say is that I have implemented a big chunk
of
> > what I wanted and I never used a tree parser and I still don't see
how
> > it would help.
> >
> >>> Think about it this way.  Imagine trying to program in Java or C++
> > and
> >>> not ever using the "." (as in computer.drives[1].head.position)
and
> >>> instead having to interrogate every object using only
> > "getFirstChild()"
> >>> and "getNextSibling()" and having only type and text information.
> >>> Imagine trying to express what I just typed? (i.e.
> >>> computer.drives[1].head.position) You get something like:
> >>> ...
> >>
> >>> Yikes!  Isn't "computer.drives[1].position.head" much simpler and
> >>> statically checkable?
> >
> >> Sure it is.  Tree grammars are appropriate for walking but not
> >> searching.
> >
> > And perhaps that is at the heart of this.  The elaboration process
> > involves working with one type definition and then constantly
expanding
> > the branches of it.  There really isn't much "searching".  There is
> > some
> > work in determining the scope for different statements and stuff but
> > that is pretty simple (compared to the elaboration semantics).
> >
> >> When you translate you typically walk the whole tree.
> >> Sometimes you index the tree with a symbol table.  But rarely do
you
> >> say 'give me the first term of the third expression in the for
loop.'
> >
> > In my current implementation, I find myself always wanting to grab a
> > specific subtree and having to search for it (analogous to what I
> > describe above).
> >
> > Furthermore, I suspect part of the applicability of tree walking
> > involves what order you do things in.  At any given level in my tree
I
> > start at that level, do several passes only at that level (and doing
> > different things) and then I recursively follow that procedure for
each
> > child.  It seems like this juxtaposes the order that is more natural
> > for
> > tree walkers which would be to do one task (e.g. scope resolution)
for
> > the whole tree and then do another task for the whole tree.
> >
> > You can read the instantiation process in the Modelica specification
> > and
> > if you see a natural way to map it into a tree parser, let me know.
> > Keep in mind that the scoping rules in Modelica are a little
difficult
> > from a compiler writer point of view (lots of non-fully qualified
type
> > names to deal with).  Scoping also involves traversal of both the
type
> > hierarchy and the "instance hierarchy" (the elaborated tree).
> >
> >> Monty
> >
> > --
> > Mike
> 
> 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/