Re: [Opencxx-users] Next tasks

[Stefan S. <se...@sy...>]

Gilles J. Seguin wrote:

> About 'my branch', I am puzzle.
> Does this branch is in opencxx or synopsis.
> If in opencxx, I was under the impression that modification in CVS
> where sending email to ope...@li....
> What is the name of the branch.  I may not be aware of a lot of
> work you have been doing.
> I am tracking through syn...@fr...

yeah, I'm talking about synopsis. Sorry if that wasn't clear.
And again, half of my checkins don't show up on the synopsis-changes
list as the diffs are so big that it wouldn't make sense to mail
them. I'll patch the commit-email.pl script some day to skip the
diffs if they exceed some size...

>>We should, however, discuss to find out whether we can agree on common
>>goals, and if so, on the means to get there. If that is done, we may
>>think about whether it is worth to merge, and how.
>>Let's do one step at a time.
> 
> 
> One step that I have try to do is documenting the grammar.
> My goal was to derive tests that verify that this grammar correspond
> to what the program is doing.  And also validate that changed codes
> do not produce unforeseen effects.

right, that's what regression tests are all about, aren't they ?

> My suggestion will be to used grammar with the PCCTS style.
> What I try to get from the PCCTS style grammar is,
> the semantic|syntactic predicates.
> 
> Semantic predicate is a parsing decision, on choice of alternative rules
> based, from information not available to a pure LL(k) parser.
> For example, bool isTypeSpecifier() is the implementation of a
> syntactic predicate.
> a:= (A)* B
> a:= (A)* C
> is now
> a:= ( (A)* B )? (A)* B
> a:= (A)* C
> more information from "Language Translation Using PCCTS and C++"
> see  <http://www.antlr.org/book.pcctsbk.pdf> page 28
> 
> Can you qualify relevance of this grammar
> (important, urgent, not useful, later)

yes, any test with a somewhat good coverage of potential input will help
us. If you can come up with either some test applets or simply a set of
input files that feature all the important language constructs we should
test the parser against, I'll help us a lot.

>>This involves a lot of reverse-engineering (for me at least,
>>as my understanding of opencxx is still limitted),
>>as well as the setup of lots of applets to demonstrates how opencxx
>>is working (unit tests are the best means for that).
>>I'v been doing this with synopsis over the last couple of weeks, and
>>I hope I can help you do the same with opencxx, so we can compare.
> 
> 
> It is a must on my list. It is important and urgent.
> That is, duplicate the qmtest from synopsis,
> Stephan is this what you are referring to, confirm.

yep, it is. In fact, with some luck I could check in some basic test
harness into opencxx mainline still tonight, within which we then can
add test applets as well as input files (as the ones you are proposing
above).

Regards,
		Stefan