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

Hi,

So now I have a new problem -- When I want to quantify a rule using (s) or (s?), the environment converts everything (including and after) the 's' to reserved perl data types. I use EPIC (in eclipse) and reserved words are in light-purple text.

 sub_exp : identifier{s} '(' expression(s?) ')' });

In this example, every character is purple starting from the 's' up until the semi-colon. However, {s} does not seem to trigger the reserved 's'-- only parens do. This has been frustrating because no example I have seen describes or outlines an issue such as this. I will also post this in the EPIC message board to see if this is an IDE issue. I posted here first to see if anyone would have any ideas :-)

Replies are listed 'Best First'.
Re: Parsing and Translation
by jethro (Monsignor) on Jul 16, 2010 at 15:12 UTC

    I had to google 4Test and found out it is an object-oriented language similar to C++.

    If you look around you will not find any complete language converters between perl, java, c++, python... because that is far from trivial. Only writing a parser for such a language is a project that is measured in months

    Your only hope may be to concentrate on a subset of the language and accept failure on some scripts, maybe even accept that translations may be defect without being able to detect that.

    For parsing I can recommend Parse::RecDescent, as long as the language is highly structured. I wouldn't want to parse perl itself with RecDescent, but a clean parser-friendly language or a suitable subset might be acceptable

Re: Parsing and Translation
by wazoox (Prior) on Jul 16, 2010 at 14:43 UTC

    I don't know what 4Test code is, however unless it's extremely simple simple regexp won't cut it. You should look into Parse::RecDescent and similar parser modules instead.

Re: Parsing and Translation
by roboticus (Chancellor) on Jul 16, 2010 at 22:04 UTC

    speedyshady:

    I've had to do similar language translations before. As mentioned previously, doing it perfectly is a rather large job. However, it's often easy to get an 85%+ solution working fairly simply. If you're the one writing the 4Test code, then it's even simpler, as you can avoid many constructions that you have difficulty translating.

    The way I've handled it in the past is to learn to recognize certain items, and translate them. Start with the simplest. Feel free to make assumptions[1]. Then, during your translation process, print anything untranslatable to the screen, so you can see what construction to attack next. I generally choose either the most frequently-seen item on the screen or the simplest one among those remaining.

    Then, as your program evolves, you'll fix broken assumptions, restructure parts of your code to do a better job, etc. You'll also find a good place to stop--after all, unless (a) you're really good, (b) you have plenty of spare time, and (c) you have no life, you'll eventually stop improving it. You'll likely have to translate a few things by hand here and there.

    ...roboticus

    [1] You might, for example, choose to assume that expressions fit on a single line. If you normally code that way, you can probably get away with it for a good while.

      Thanks for all of your help, guys! The Parse::RecDescent module is a gem for this. It's exactly what I needed. I've written an intepreter in Scheme and this mirrors the sllgen generator, so it should be smooth sailing from here.