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

Monty Zukowski monty at codetransform.com
Thu Jul 8 13:02:50 PDT 2004


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

<*> 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/
 



More information about the antlr-interest mailing list