On Thu, May 8, 2014 at 9:04 AM, clueless newbie <li.hansen....@gmail.com>wrote:
> It's just my guess that the first step is to get the SLIF to successfully > parse COBOL. After that pulling stats related to the frequency of > occurrence of statement, which would suggest where the biggest bang for the > buck is to be found. > This can be the cart before the horse. >From my experience, a translation (esp. an untrivial, idiomatic one) frequently needs a different AST than, e.g., pretty printing, for they are different semantics. So, trivial as it may be, if you need to translate, start with a dictionary. A pattern dicitonary that is. A pattern is: this piece of COBOL translates to that chunk of Perl, with the needed substitutions. A piece or chunk can be a module, a sub or a code fragment. You can define patterns based on frequency (Sequitur algorithm <http://goo.gl/JJzxub> can help here) or idiomaticity or priority. Once you have patterns, you can build your parser around them and build your translator as a filter — parse what you can translate, pass through (comment out) what you can't. Thus the dev can be split to more manageable dictionary/parser/translator refinement cycles. That looks sort of like what they're doing now with Perl regexps, but more structured and future-proof, so to say. Hope this helps, -- rns. > > > On Wednesday, May 7, 2014 2:04:54 PM UTC-5, Jeffrey Kegler wrote: > >> I was about to advise an incremental approach, so you're ahead of me. >> You'll find that Marpa lends itself very nicely to an incremental approach. >> >> Is the COBOL standard freely available? And which one are you targeting? >> >> -- jeffrey >> >> On 05/07/2014 12:01 PM, clueless newbie wrote: >> >> With COBOL being as "verbose" as it is, just being able to parse the >> classic "Hello, World" program would be a great start. Obviously the first >> thing one does is kill the meaningless chaff (the sequence name area and >> the program name area) then concatenate the lines that are continuation >> with their predecessor. >> >> COBOL BNF <http://tomcopeland.blogs.com/cobol.html> Another COBOL >> BNF<http://www.cs.vu.nl/%7Ex/grammars/vs-cobol-ii/index.html> >> >> On Wednesday, May 7, 2014 1:39:17 PM UTC-5, Jeffrey Kegler wrote: >>> >>> By the way, if you prefer IRC, there's an IRC channel -- >>> irc.freenode.net: #marpa >>> >>> You've gotten me curious enough to go to the COBOL Wikipedia pages. And >>> others in the Marpa community have done transpilers -- we have a ECMAScript >>> transpiler and a C compiler frontend, so there is a fair amount of relevant >>> experience out there. Though I suspect the COBOL expertise is a bit thin. >>> :-) >>> >>> -- jeffrey >>> >>> On 05/07/2014 11:33 AM, clueless newbie wrote: >>> >>> Being that no one in authority at Company A is going to say ... "Let's >>> use the Marpa approach", I'm going to have to attack this on my own time. >>> And since I'm certainly not capable of accomplishing it on my own it would >>> very much have to be open sourced. >>> >>> >>> -- >> 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 marpa-parser...@googlegroups.com. >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- > 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 marpa-parser+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 marpa-parser+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
