Related articles |
---|
Looking beyond the Parser Compiler: Request for insight towards what's alexander.morou@gmail.com (Alexander Morou) (2009-09-08) |
From: | Alexander Morou <alexander.morou@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Tue, 8 Sep 2009 17:09:03 -0500 |
Organization: | Compilers Central |
Keywords: | question, design |
Posted-Date: | 09 Sep 2009 11:16:12 EDT |
Over the past two and a half years or so I've been working on a
project named Oilexer to teach myself the basics of language theory.
Here in a few months it should be moving past the boot-strapper
phase.
I'll use the bootstrapper to build the first official version, so I
wanted to get a few ideas on what would be useful to others
interested in using a parser compiler.
I already plan on having templates (in the bootstrapper they support
variadic parameters for expanding sets of terms, like operator
precedences in mathematical operations).
If possible I'd like some ideas what's convenient for supporting
match actions in the scanner as well as the parser itself. Mostly
related to syntax, and perhaps where the best possible point to
execute the code would be (during parse, during parse graph
construction, both, or otherwise).
I'm also developing a compiler framework which I'll use for the
translation of the general-purpose code model into Common
Intermediate Language (I haven't decided whether I'll just emit IL
through text, or through using something like the Common Compiler
Infrastructure on Codeplex).
My ultimate goal with all of this is to write my own high level
language which supports heavy code generation and integrates language
theory concepts. I think it would be interesting to see a language
which has good innate (fast) support for pattern matching and code
automation, in a way that's capturable for reuse/expansion by others.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.