[CEDET-devel] Re[4]: Parsing method bodies

[Eric M. L. <er...@si...>]

>>> Paul Kinnucan <pa...@ma...> seems to think that:
>Eric M. Ludlam writes:
> > Paul has some nifty ideas below for JDE related parsing.  There are
> > two suggestions below.  1) is copy David's parser, and add in new
> > actions.  2) is to create a special kind of parse tree that can be
> > visited.
> > 
> > 1 sounds like a maintenance nightmare over the long haul.
> > 
> > 2 sounds like a good idea with some small exceptions.  2 is the
> > approach used for tagging.  All parsers generate some predictable
> > output and we have a huge API dedicated to extracting useful bits out
> > of it.  The type of that output has been managed, adjusted, pruned,
> > extended and taunted for several years to be where it is.  Will we
> > have to do that again to make a language agnostic representation of
> > method bodies?
>
>The advantage of the parse-tree-visitor approach is that it provides
>true language independence, e.g., you don't have to make compromises
  [ ... ]

Hi Paul.  Thanks for the explanation.  The wording of your original
message was too subtle for me to recall that parsing mode, despite the
fact that we had talked about it at length in the past.  I remember
and understand now what you were originally saying.

When the time comes I hope to remember this.  When choosing what to
do, this is my thought process:

goal: Once a user turns semantic on, it must be fast and accurate
  enough to make them never want to turn it off.

I tend to be my worst critic as I accept no guff from Emacs and turn
my tools off when they get in the way.

Anyway, to make this goal, I go for the fastest mechanism possible
which explains the fast number of short cuts taken to get those tag
tables.

Somewhat less important is the overall size of the data captured.  I'm
not really sure what to do about the vast amounts of data captured in
method body parsing.  It is needed for true refactoring mechanisms.
Would a refactoring tool just parse through everything as it goes or
would we cache it all for speed at that time.  How big would those
tables be?

Hmmm, I wonder if I could automatically run semantic.cache files
through gzip.  That would be cool.

Anyway, I don't know where your parser style fits with those goals.
It might be easier to continue to the use of the existing, and quite
flexible tagging format David created and create EIEIO objects for
visiting those tables in a structured way.  This would be similar to
the existing override methods, with the advantage of storage while
traversing a parse tree.  I know that is very different from what you
describe, but it might provide the flexibility you are looking for.

Anyway, as I won't get to it for quite a while, if you and David
follow this trail to the end I will watch with interest and provide
what feedback I can.

Thanks
Eric

-- 
          Eric Ludlam:                 za...@gn..., er...@si...
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org