Re: .NET Compiler for Interactive Fiction

TJB Replied to the following:


> This is exactly the thought process I'm going through. This is what
> makes the CLR so interesting. Of couse now that I've actually read
> through a couple of compiler books, I'm not sure I should even be
> talking about this. Until I find a true compiler person interested in
> helping me, I doubt I'll get anywhere.


Well, I'm not a "TRUE" compiler person. A year ago, I started off in
the same boat as you are now. Parsing is the biggest problem to
solve, but there are others. I started out by reading everything I
could about language theory and grammar theory. You should get a
rough idea of the difference between LR and LL and understand the
concept of tokens of look ahead. None of this is really that
difficult to learn or even to put into practice, but, it does take
some work. I admit that I've still got a ways to go, but I have
written my own compiler for my own virtual machine, and did so by
myself, so what you propose is certainly possible.


>
> Still working...
>


Keep at it. You can do it. I would recommend perhaps starting out with
the Dragon book, but you can still get a lot of what you need off the
internet if you can't spring the $100.


A quick overview. compilers start to stop. To build a compiler, your
program will generally solve these problems:


a) breaking arbitrary items of text into short little strings, or
tokens. Most people use a form of a regular expressions for this.
Existing programs that do this are like "lex", etc. Perl could be
used for this as well.


b) identifying language constructs from lists of these little tokens.
This is a biggy. Broadly put, AFAIK, there are two main ways for
doing this. The first is recursive descent, and the second is shift
reduce. recursive descent is simpler to do at first but can run into
some problems with certain kinds of grammars. There's another called
shift reduce, which I thought was a magic bullet but it has some
issues to.


It turns out that the act of writing a parser can be separated from
the language specification. You can define a language by a few simple
set of rules, and feed that into a parser generator. yacc is the
quintessential example of this, and there are others and many are
better. Basically, a parser generator let's you take grammar rules
like expr -> expr + expr, and all you have to do is shove your lexxed
tokens into it, and then write the code generation / tree building
piece on the other side. Basically, the output that you get from the
parser might be something you can use directly in your language, or
you have to manhandle it a bit. Serious compilers take this parsed
stuff and throw it into a "parse tree". The final code generation
comes from taking this parse tree and producing different code for
each of the nodes. But for a lot of simple things don't require you
to have a parse tree - like, simple expression evaluation does not...


If I butchered this too badly, will some brighter light please step
in.

Return to the comp.compilers page.
Search the comp.compilers archives again.