(Editor's Name):

    In our original discussions over the phone, we decided on four articles
on Toy. There is a possibility for a fifth. That one would show the system
interface file and the run-time-system generator file. Those files are
included here for completeness, since we want the disk subscribers to have
the whole compiler. As you can see, however, they are fairly complicated.
Readers might be interested in the AmigaDOS object file generation stuff in
particular.

    Another possiblity is a shorter series on an interpreter for the same
language. It could consist of one article outlining the methods of
interpretation, and showing some of the changes to the Toy code needed to
turn it into an interpretive system. The second article would show details
of the interpretation process. I've done an interpreter like this for a
similar language, but I would have to convert it to the Toy language.

    If you are interested in either of these possibilities, let me know as
soon as possible. Basically, choose one of these three endings to article
number 4, add it to the article text, and let me know which you choose. Yet
another alternative is to start adding more features to Toy (such as more
complex types, so we can do arrays, etc.), but I haven't really thought
much about that yet.


Ending #1:
-----------------
	In this series of articles I have tried to present some of the
    basic ideas and methods involved in writing a compiler. A small
    language, called "Toy" has been described, and a compiler for it shown.
    The complete source for the Amiga Toy compiler is available on the disk
    version of this magazine, and the important parts of that source have
    been shown in the magazine and explained. In many places I have
    discussed some of the difficulties and choices facing a compiler
    writer, and have presented alternatives to what is done in Toy. I have
    used the shareware Draco compiler as an example of a more complete
    compiler when discussing more advanced features. I hope I have
    encouraged a few people to look into working on compilers of their own,
    perhaps based on Toy. I also hope I have shed some light on why
    compilers often seem to do strange things.
-----------------

Ending #2:
-----------------
	In this article I have discussed the code generator for the Toy
    compiler, showing how it operates and what it produces. I have also
    discussed a number of changes that could be made to improve it. A very
    brief mention of some of the standard compiler optimization techniques
    was also given.

	There are two major components of the Toy compiler left to discuss.
    These are the system interface code and the run-time-system. The system
    interface code is of interest mainly because it generates an AmigaDOS
    object file, which are different in flavour from those of most
    operating systems. The run-time-system code itself is fairly simple.
    What is of interest here is that it is emitted directly by the compiler
    itself, using some fairly weird techniques. These two components will
    be examined in next month's article.
-----------------

Ending #3:
-----------------
	In this series of articles I have tried to present some of the
    basic ideas and methods involved in writing a compiler. A small
    language, called "Toy" has been described, and a compiler for it shown.
    The complete source for the Amiga Toy compiler is available on the disk
    version of this magazine, and the important parts of that source have
    been shown in the magazine and explained. In many places I have
    discussed some of the difficulties and choices facing a compiler
    writer, and have presented alternatives to what is done in Toy. I have
    used the shareware Draco compiler as an example of a more complete
    compiler when discussing more advanced features. I hope I have
    encouraged a few people to look into working on compilers of their own,
    perhaps based on Toy. I also hope I have shed some light on why
    compilers often seem to do strange things.

	Another type of programming system is the interpretive one. Here,
    an internal data structure is traversed by the CPU to execute the
    user's program. This is somewhat slower than equivalent machine code
    produced by a compiler, but has the advantage of being immediately
    executable. Interpreters can also present a better debugging
    environment, and can allow interactive experimentation. Next month, I
    will look at producing an interpreter for the Toy language.
-----------------