Both valid points; round-tripping just might look good from the outside as a test/demo case, even if more demo than test.
On Wed, Dec 25, 2013 at 10:27 AM, Jeffrey Kegler < [email protected]> wrote: > The point may be a bit pedantic, but the "A" in AST stands for > "abstract", which suggests that some information is lost, and that a > round-trip from text to text via an AST would not be possible. On the > other hand, in current use, "AST" tends to mean simply "syntax tree". -- > jeffrey > > -- jeffrey > > On 12/24/2013 11:48 PM, Ruslan Shvedov wrote: > > On Wed, Dec 25, 2013 at 8:13 AM, Durand Jean-Damien < > [email protected]> wrote: > >> Thanks for this feedback. All of them has been pushed on my todo list, >> and you will get feedback progressively. >> >> Right now, I have fixed the grammar (gcc __extension__ keyword was >> misplaced) and have released a new version of MarpaX::Languages::C::AST. >> Which parses successfully the perl-5.18.1 sources, increasing the >> confidence level on c2ast.pl to a quite high value -; >> > Great news; congratulations. > > I just wondered can it be useful if MarpaX::Languages::C::AST had a > dump() method to re-produce the source C text? > > Such reproduced file would then be shown > > to be the same as the original C (no textual diff, sans whitespace > perhaps) > to do the same (no binary diff perhaps?) as the original C file when > compiled with the same compiler. > > > Naive as it is, but hopefully helpful? > > >> >> Thanks / JD. >> >> Le mercredi 25 décembre 2013 01:08:22 UTC+1, Jeffrey Kegler a écrit : >> >>> As I've said before, I think this C parser is a remarkable new tool, >>> something that has been needed for decades. Getting out the last few nits >>> is annoying, but each of those last few steps adds a surprising amount to >>> way the user experiences the tool. >>> >>> By the way, when I was using it (and I encountered no bugs when using it >>> to deal with the Marpa source), I did note some things which I thought >>> might make the tool more "cuddly" from the user's point of view. >>> >>> 1.) An option (--stdin?) to accept the pre-processed C source on >>> standard input. This makes getting things right with the options easier. >>> You first get the pre-processor options right, separately. Then you can >>> eyeball the pre-processed C to see it's right. Finally, you work out the >>> (now far fewer) options to c2ast. And with a --stdin option, you can do >>> other things like capture the pre-processed C in a file, for debugging. >>> >>> 2.) More error messages on the c2ast.pl options. In particular, I had >>> a lot of problems with it "failing" silently when I got the options wrong. >>> c2ast.pl was not really failing -- it's just that I did not have the >>> options right. But I think the option processing in c2ast could be more >>> helpful. >>> >>> 3.) Factor the checking of reserved names into a separate tool, perhaps >>> c_reserved.pl. This would make the options even simpler. Also, I >>> think a separate c_reserved.pl could then act as an example of the use >>> of MarpaX::Languages::C::AST for study. >>> >>> Thanks, jeffrey >>> >>> On 12/24/2013 02:59 PM, Durand Jean-Damien wrote: >>> >>> Damned, c2ast failure on gcc __extension__, ... Will see tomorrow -; >>> Probably another release of MarpaX::Languages:C::AST when fix found. >>> >>> else if ((!__extension__ ({ size_t __s1_len, ... >>> --------------------------^ >>> Uncaught exception from user code: >>> at /usr/local/share/perl/5.18.1/MarpaX/Languages/C/AST.pm line >>> 109. >>> MarpaX::Languages::C::AST::Util::logCroak('%s\x{a}Last >>> position:\x{a}\x{a}%s%s', 'Error in SLIF parse: No lexemes accepted at line >>> 18736, colum...', 'line:column 18736:27 (Unicode newline count) 18736:27 >>> (\n cou...', '') called at >>> /usr/local/share/perl/5.18.1/MarpaX/Languages/C/AST.pm line 109 >>> >>> MarpaX::Languages::C::AST::parse('MarpaX::Languages::C::AST=HASH(0xb392654)', >>> 'SCALAR(0xa702f78)') called at /usr/local/bin/c2ast.pl line 126 >>> >>> >>> Le mardi 24 décembre 2013 19:35:14 UTC+1, Jeffrey Kegler a écrit : >>>> >>>> A blog post sounds good. More people should know about this issue -- >>>> even if you don't find fixing legacy code to be worth the bother, it *is* >>>> good to know enough not to write new code with reserved names. And p5p, >>>> etc., will then be free to give the current issues in the Perl source >>>> whatever priority they see as appropriate. >>>> >>>> As context, the C standards reserve certain names to the >>>> "implementation", which means the compiler implementation, including the C >>>> libraries. Your own applications and libraries are not allowed to use >>>> reserved names. These names were reserved back before namespace issues >>>> were well understood. In many cases there are unnecessarily overbroad and >>>> can be called mistakes, but they are mistakes that we are stuck with. I >>>> personally find the bans on E[A-Z0-9]*, is[a-z]* and to[a-z]* all to be >>>> real nuisance. If you have a variable named "token", you are using >>>> reserved namespace, and an implementation upgrade could cause unspecified >>>> behavior as a result. Or how about the "stream_state" variable? Banned -- >>>> str[a-z]* is reserved for new string functions. The GNU docs summarize them >>>> nicely >>>> here<http://www.gnu.org/software/libc/manual/html_mono/libc.html#Reserved-Names> >>>> . >>>> >>>> The full list is hard to memorize and C programmers, even at the >>>> highest skill level, often ignore them. Before Jean-Damien created it at >>>> my request, there was (as far as I know) no tool to detect violations. I >>>> was aware of these issues, and believed that I was writing Marpa to be >>>> fully compliant, but c2ast.pl found many issues I'd missed. >>>> >>>> So a blog post would be a real service. >>>> >>>> -- jeffrey >>>> >>>> On 12/24/2013 07:08 AM, Durand Jean-Damien wrote: >>>> >>>> Jeffrey, >>>> >>>> Nice idea, I'll do so, guessing that posting to blogs.perl.org could >>>> have a better and perhaps more appreciated audience than directly to p5p or >>>> perlbug (?). >>>> >>>> Thanks / JD. >>>> >>>> 2013/12/24 Jeffrey Kegler <[email protected]> >>>> >>>>> [ Off-line from the group ] An exercise which might help the Perl >>>>> community (and in the process bring attention to c2ast), would be to run a >>>>> c2ast.pl --check reservedNames on the Perl source, and submit it to >>>>> perl5-porters (or perlbug?). >>>>> >>>>> [...] Cleaning up the namespace will be hard -- the Perl source >>>>> intrudes on the reserved namespace heavily. And many people may not >>>>> realize the reason to keep the namespace clean -- it'll seem like a lot of >>>>> work to deal with something that is not an issue. >>>>> >>>>> I'm emailing you direct off-line because you're the obvious >>>>> first-choice to do this. If you like the idea, reply back into the main >>>>> list. Otherwise, I may throw this open to the list as a "Target of >>>>> Opportunity". >>>>> >>>>> -- jeffrey >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "marpa parser" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "marpa parser" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "marpa parser" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > You received this message because you are subscribed to the Google Groups > "marpa parser" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to the Google Groups > "marpa parser" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
