[antlr-interest] Re: woohoo! ParseTrees for free, Debugging f or me!

[lgcraymer]

--- In antlr-interest at yahoogroups.com, mzukowski at y... wrote:
> Yeah, I guess it depends on what your "unit" is.  Rules aren't really
> methods, they're too interdependent, so a rule test just doesn't fly.  But
> if you want to say your unit is a parser, then, OK I buy that.  My unit is a
> "feature" like typedef or nested conditionals.  Boy this is a bogus
> argument.  Never mind.

Actually, the line of thought is useful.  The differences are semantic--you're thinking in terms of diagnostic units, while Ter is talking 
implementation units.  The big advantage of source-to-source translation for testing is that the output is readily comprehensible by 
humans and you can put together simple diagnostic test cases.  That's still very much functional testing--the translator is treated as a 
black box.  The grammar testing (that Ter's made a strong start at) tests a grammar as an implementation unit, with enough visibility 
to get "rule" level diagnostic information.  I put "rule" in quotes because the problems are usually interactions between rules, not 
necessarily local to a rule.

The pieces still missing are the token (source) mapping that you suggested, and some useful presentation of ANTLR decision 
making.  Interestingly, Ter's approach would print flattened rules, and you'd also want a syntax tree to parse tree mapping.  (My tree 
grammar generation stuff might be adequate, but I think that there's a better approach lurking here.)  Printing $FIRST and $FOLLOW 
sets would be overwhelming; there must be some useful way of extracting the equivalent diagnostic information in a comprehensible 
form.

--Loring

> Somewhere my point was going to be that changing your parser around to
> accommodate tree building will break your derivation and hence your unit
> test.  So they need to be easy to fix.
> 
> However I'm looking forward to thrashing out a viable testing strategy for
> parsers and translators.  For C, anyway, it's not been a problem to have
> entire programs be the "unit" tested because they can still be small.  
> 
> Monty
> 
> -----Original Message-----
> From: Terence Parr [mailto:parrt at c...] 
> Sent: Tuesday, December 02, 2003 8:32 AM
> To: antlr-interest at yahoogroups.com
> Subject: Re: [antlr-interest] Re: woohoo! ParseTrees for free, Debugging f
> or me!
> 
> 
> On Tuesday, December 2, 2003, at 07:01  AM, mzukowski at y... wrote:
> 
> > This is really cool!  Any chance of getting the actual tokens matched 
> > by the
> > rule in that derivation?  That's the other thing I look at when using
> > -traceParser.
> 
> Sure...I'll combine with my TokenStreamTracker (next little goodie to 
> release, which is an extension / simplification of the "preserving 
> token order with trees" article).
> 
> > As for a test harness--yeah, that's cool for just doing parsers, but my
> > preferred approach, a la the GCC toolkit
> > http://www.codetransform.com/gcc.html, is to go from source to source 
> > and
> > then make sure you've got the same thing (minus some whitespace).
> 
> That is more functional that unit testing...unit testing in *addition* 
> could be good so we can more precisely identify where the problem is.  
> The functional testing would test more of the translation rather than 
> the parsing....good to have both. :)
> 
> Ter
> 
> >
> > Monty
> >
> > -----Original Message-----
> > From: Terence Parr [mailto:parrt at c...]
> > Sent: Sunday, November 30, 2003 10:07 AM
> > To: antlr-interest at yahoogroups.com
> > Subject: Re: [antlr-interest] Re: woohoo! ParseTrees for free, 
> > Debugging for
> > me!
> >
> >
> >
> > On Sunday, November 30, 2003, at 12:16  AM, lgcraymer wrote:
> >
> >> --- In antlr-interest at yahoogroups.com, Terence Parr <parrt at c...>
> >> wrote:
> >>>
> >>> On Saturday, November 29, 2003, at 10:16  PM, lgcraymer wrote:
> >>>
> >>>> Ter--
> >>>>
> >>>> If I interpret this right, you're actually visualizing parse
> >> trees
> >>>> without generating them.
> >>>
> >>> Nope, i build parse trees and then rewalk them to get step i of
> >>> derivation.  You can ask for any intermediate step or all of 'em :)
> >>
> >> That is impressive, then--you've discovered a whole new approach to
> >> instrumenting ANTLR.  I assume that you've made the overrides user
> >> programmable?
> >
> > Well, for now it's just an "article" on the website with some sample
> > code...later we'd have to allow people to specify their own parse tree
> > nodes instead of my simple ones...  As for user programmable, for now,
> > you can turn on or off by adding the overrides and turning on/off
> > -traceParser.
> >
> >>   It sounds like an approach that might support an
> >> ANTLR test harness for grammars.
> >
> > Heh yeah!  That's a great idea, dude!  Sweet!  This way we can check to
> > see if all derivation steps are identical.  Previously, testing parsers
> > was really hard as it says yes or no depending on errors; that's all.
> >   Answering "yes" is not much of a test as an empty main program gives
> > the same answer. ;)  Yeah!  This is the testing harness I've been
> > afraid would be extremely difficult!  We've got it, by jove!
> >
> >
> >
> > Your use of Yahoo! Groups is subject to 
> > http://docs.yahoo.com/info/terms/
> >
> >
> >
> --
> Professor Comp. Sci., University of San Francisco
> Creator, ANTLR Parser Generator, http://www.antlr.org
> Co-founder, http://www.jguru.com
> Co-founder, http://www.knowspam.net enjoy email again!
> Co-founder, http://www.peerscope.com link sharing, pure-n-simple
> 
> 
> 
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


 

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