Re: .NET Compiler for Interactive Fiction

tbandrow@unitedsoftworks.com (tj bandrowsky)
16 Mar 2003 23:58:36 -0500

          From comp.compilers

Related articles
[3 earlier articles]
Re: .NET Compiler for Interactive Fiction david.cornelson@iflibrary.com (David A. Cornelson) (2003-03-09)
Re: .NET Compiler for Interactive Fiction tbandrow@unitedsoftworks.com (2003-03-09)
Re: .NET Compiler for Interactive Fiction neelk@alum.mit.edu (Neelakantan Krishnaswami) (2003-03-14)
Re: .NET Compiler for Interactive Fiction lars@bearnip.com (2003-03-14)
Re: .NET Compiler for Interactive Fiction david.cornelson@iflibrary.com (David A. Cornelson) (2003-03-14)
Re: .NET Compiler for Interactive Fiction marcov@toad.stack.nl (Marco van de Voort) (2003-03-14)
Re: .NET Compiler for Interactive Fiction tbandrow@unitedsoftworks.com (2003-03-16)
Re: .NET Compiler for Interactive Fiction tbandrow@unitedsoftworks.com (2003-03-16)
Re: .NET Compiler for Interactive Fiction lex@cc.gatech.edu (Lex Spoon) (2003-03-17)
Re: .NET Compiler for Interactive Fiction david.cornelson@iflibrary.com (David A. Cornelson) (2003-03-17)
Re: .NET Compiler for Interactive Fiction JeffKenton@attbi.com (Jeff Kenton) (2003-04-05)
Re: .NET Compiler for Interactive Fiction joachim_d@gmx.de (Joachim Durchholz) (2003-04-13)
Re: parsing, was .NET Compiler for Interactive Fiction rpboland@math.uwaterloo.ca (Ralph P. Boland) (2003-04-15)
[17 later articles]
| List of all articles for this month |

From: tbandrow@unitedsoftworks.com (tj bandrowsky)
Newsgroups: comp.compilers
Date: 16 Mar 2003 23:58:36 -0500
Organization: http://groups.google.com/
References: 03-02-125 03-02-147 03-03-043 03-03-061
Keywords: design
Posted-Date: 16 Mar 2003 23:58:36 EST

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.



Post a followup to this message

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