Translating from one programming language to another automated

brianarn has asked for the wisdom of the Perl Monks concerning the following question:

I've got a question or two about some methodologies on token parsing - I've read Parsing, tokens and strings, and I got some ideas from it, but this project I may be taking on is a bit bigger than what's detailed there.

My brother-in-law is wanting to come up with a VHDL-to-spice parser, which are both languages he has to use in his chip design job. We've talked a little bit about writing a much more intelligent parser than they already have to do this task, but I don't know VHDL or spice, and he doesn't know enough Perl or C or any other languages to do this.

I've written a token parser once in C for a class, but it would seem to me that Perl is much more suited to the task, as it's processing text into text. I've also been reading through Perl & XML, and that's given me some other ideas too - I don't have any real pseudocode at this point, but I'm wanting to consider methodology.

When I wrote the parser in C, we basically read in elements that were nonwhitespace, and then ran each token through a switch, where further tokens were pulled off, etc.

Now, with Perl, I can read in a whole line at a time, split it, and then run through the array, but when I run into multiline blocks, that doesn't seem like it'd work as well.

I'd thought of slurping the entire file up into one big fat scalar, then using split limited to two elements, so that I have something akin to a current token, and the rest of the code to come, so the fact that whitespace exists isn't an issue anymore. This approach seems very undesirable, because if he's running it on incredibly large files, it'll eat RAM like there's no tomorrow, AFAIK.

In Perl & XML, there is an example of using XML::Parser to read through an Apache logfile, by defining how the parse function works. That'd be an interesting approach, using something like that and a nice big symbol table of sorts to take care of it.

Has anyone attempted anything like this in the past? I know that there are simple ____2____ sorts of programs out there, but I haven't really read any language2language source code, and so I'm posting this in hopes of getting some good feedback.

~Brian

Comment on Translating from one programming language to another automated

Replies are listed 'Best First'.
Re: Translating from one programming language to another automated by kvale (Monsignor) on Jul 15, 2002 at 22:37 UTC
To translate one language into another, you need in general to write a compiler. This involves lexing the text to get tokens, parsing the tokens into an intermediate language or syntax tree, and stepping through the tree to generate the code for your new language. In perl, lexing is easily taken care of using regexps. People oftern turn to Parse::RecDescent for parsing and conversion needs. If you have used Yacc or Bison in the C world, this module should be very easy. A necessary ingredient for this is a VHDL grammar . The grammar describes the structure of the language and will handle things like multi-line statements automatically. It is also possible to write your own parser, creating a top-down structure in which each nonterminal in your grammar is represented by a subroutine, but it is more work and more error prone than using Parse::RecDescent. -Mark	[reply]
Re: Translating from one programming language to another automated by Elian (Parson) on Jul 15, 2002 at 22:28 UTC
What you're looking to write here isn't a translator. It's a compiler, and this is a nontrivial piece of work. You're lucky to some extent that VHDL and Spice are pretty close in terms of features (sorta) so it's less of an issue than a PL/I to Fortran converter, for example. Still, this is a Tough Problem. I'd take a look at Parse::RecDescent, Parse::YAPP, and the command line tools lex and yacc. A good compiler book wouldn't be out of order either.	[reply]
Re: Translating from one programming language to another automated by Abigail-II (Bishop) on Jul 16, 2002 at 11:25 UTC
`Parse::RecDescent` has been mentioned by other posters. `Parse::RecDescent` can certainly do the job, but will it be fast enough? There are two reasons why `Parse::RecDescent` is slow. First, it's written in pure Perl, and that loses on speed compared to tools written in C. Second, `Parse::RecDescent` is a tool for parsing recursive descent grammars. And that's a pretty broad class of grammars; any context insensitive grammar can be parsed with a recursive descent parser. `Parse::RecDescent` generates trial-and-error parsers, all branches will be tested, until either a parse has been found, or all options have been tried. This could mean the parser consumes the entire string, figures out it cannot match, backtracks to the beginning of the string, and tries again with another rule. Yacc based grammars don't backtrack (or backtrack at most one token). By looking ahead just a single token, they can decide which rule to apply, and then they do not have to try another rule, even if the choosen rule turned out to lead to a mismatch. Subclasses of the class of context free grammars, like LL(k), LR(k), LALR(k), etc can decide which rule is needed by looking ahead a fixed number of tokens. Another thing to consider is that `Parse::RecDescent` does not have a tokenizer. It generaters combined lexer/parsers. Conclusion, `Parse::RecDescent` will very likely do the job. But it might not give the performance you are seeking. I've never worked with `Parse::YAPP`, so I will not comment on it. Abigail	[reply] [d/l] [select]
Re: Translating from one programming language to another automated by mattr (Curate) on Jul 17, 2002 at 14:20 UTC
It may be that Recdescent is what you need. I was going to comment briefly on yacc which Abigail discussed more intelligently. There is a howto description of Lex and Yacc I found through linuxdoc.com here and I also saw a reference to byacc which generates Perl code as opposed to C code which yacc apparently creates.	[reply]