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! | [reply] |
It seems like you'll have to include some examples, or maybe a single running example throughout. For (meta-)example:
- An interpreter for a basic arithmetic language.
- One for a fancier version.
- Turning that into a compiler.
- 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] |
| [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] |