May 03, 2004

Writing a parrot compiler, part 2

No, it's not done, but I'm starting in on it. The original one got sufficient of whatever O'Reilly wants from OnLamp articles to warrant a second, so...

Since there's still some (though not a whole lot) of time before I start in, this'd be a good time to weigh in with suggestions on what should be in the article. I figure on at least control flow (since, y'know, being able to do if statements is awfully nice) and maybe subroutines, but beyond that it's up in the air.

If there's a definite want of something, add a comment.

Posted by Dan at May 3, 2004 02:36 PM | TrackBack (0)
Comments

Lexicals and globals. Arrays (and maybe hashes). Objects are probably best left for part three...

It'd be really impressive if you could wedge the compiler into compreg somehow, but that may be asking for too much. (Unless your compreg handler just went out and executed "perl compiler.pl"--or more likely 'concat S0, config["perl"], " compiler.pl"'.)

Posted by: Brent at May 3, 2004 07:57 PM

While writing a compiler is really not difficult, most books don't cover how one should handle multiple source files (well, I never saw a *real* explanation of it in any book). That is, how should the compiler handle a program which consists of multiple source files. Maybe what I'm actually referring to is the linking phase, (which will be done dynamically in Parrot,right?) but the language should have some support syntax for it, like "import" in Java. And, the compiler's symbol table should be designed for it, too (right?) So, a simple explanation for that, would be nice too.

Posted by: Klaas-Jan at May 4, 2004 01:26 PM