On Wed, Dec 25, 2013 at 12:04 PM, Ruslan Shvedov <[email protected]>wrote:
> Now with ASF's traversing at hand, given that c2ast.pl produces > unambiguous parses (as it should be, I think), ASF's > become effectively AST's and the MarpaX::Languages::C::AST::dump() can be > done by simply visiting each glade and appending glade->literal() as needed > with suitable whitespace? > > Or is it not that easy? > Just remembered that it's easy only for monotonic applications which c2ast.pl must be not. > > > 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.
