in reply to Re: Writing Interpreters, Compilers and Translators in Perl
in thread Writing Interpreters, Compilers and Translators in Perl

I shortend it from "testing considerations" - there are one or two things worth saying that are well-defined and bounded, but to avoid the "can", I'll change that back to a well-defined non-wormish specification :). I'm trying to be generic about what to translate into in regard to translators, but Perl has to be the implementation language - that's a given I think for this conference!
__________________________________________________________________________________

^M Free your mind!

  • Comment on Re^2: Writing Interpreters, Compilers and Translators in Perl

Replies are listed 'Best First'.
Re^3: Writing Interpreters, Compilers and Translators in Perl
by educated_foo (Vicar) on May 25, 2007 at 14:04 UTC
    It seems like you'll have to include some examples, or maybe a single running example throughout. For (meta-)example:
    1. An interpreter for a basic arithmetic language.
    2. One for a fancier version.
    3. Turning that into a compiler.
    4. Doing something fancy with the compiler.
    Doing this in a generic way would be terribly hard. It would be much easier to choose an example source and target language, and the semantic mismatches between source and target would substantially shape your talk.

    One really cool example here would be to "compile" a subset of Ruby into Perl, to show just how little semantic difference there is. Another would be compiling X to C, since you would have to describe implementing X's runtime. Another would be translating to Perl (see e.g. my Language::FP, which has both an interpreter and a compiler), since it wouldn't require introducing a third language (even though Perl elaborate semantics make the translation tricky).

[reply]
      Another would be compiling X to C

      Or possibly to C--, since AIUI it's thought exactly for that, i.e. as a target C-like HLA.

[reply]
        Yeah, but a lot more people and architectures have C compilers, so if your goal is to portably generate reasonably fast machine code, and you don't have time to mess with low-level optimization and code generation, "gcc -O3" is the way to go.
[reply]
      Yes I think arithmetic expressions, especially with brackets, are a good idea because they most readily justify the nuts and bolts of a parse tree. But I can't completely abandon command and data translation because these are the bread and butter of most actual applications.
      __________________________________________________________________________________

      ^M Free your mind!

[reply]

In Section Seekers of Perl Wisdom