I chose to write my own tokenizer and parser because I like doing everything myself. The tokenizer is an extremely simple module and I don't see any reason to use a previously available module that may not generate the output in the format I want. The parser is indeed more complex, and if you don't know what you're doing you may be better of with an already tried and true module. Although, then you'll have to adapt your code to that output format and way of doing the parser. By writing it yourself you get to choose exactly what it should do and how it should do it.

Some things I would have done differently:

1. Don't use native calling conventions. They are very difficult to make portable. Use a generic calling convention, for which wrappers can be written through the use of templates.

2. Don't use statically typed variables. Your compiler and virtual machine will be much less complex by using dynamically type variables.

3. Don't add complex syntax structures until you have the rest completed.

4. Let the script library choose the available ways of binding objects, functions, and class interfaces. This will reduce complexity in the code and make it easier to maintain.

5. Limit the way memory is passed between VM and application. This will give you more flexibility in designing your memory management.

and so on. Of course had I followed all these advices, I might as well not have written AngelScript at all, since all of these are already covered by script libraries such as Lua, Squirrel, etc.

What makes AngelScript different from the other script libraries are exactly these points, because I didn't shy away from the added complexity, in favour of making the library interact more easily with the application and making the language more similar to C++ than other script languages. Without these differences, there would be no reason for others to use AngelScript.

So that may be another thing for you to think about. If you want to just write a script library for your own fun, then follow the above advices as it will be much easier for you. If you want to write a script library that you want others to use, then you have to find a way to add advantages over other already existing libraries, which may not always be an easy task.

AngelScript has been in the works for almost 4 years now, and I'm still not finished with it. If you're not ready to make such a commitment, then you had better set simpler goals for yourself.

Regards,
Andreas

Quote: 1. Don't use native calling conventions. They are very difficult to make portable. Use a generic calling convention, for which wrappers can be written through the use of templates.

2. Don't use statically typed variables. Your compiler and virtual machine will be much less complex by using dynamically type variables.

For the record, these were the selling points for me when I started using AngelScript.

I have some collected links here: http://www.angelcode.com/refdb/category/31.asp. I'm afraid I cannot recommend any books on this subject. I don't read a whole lot books, I prefer learning from articles on the internet instead, which is free and always updated.

I remember my first version of AngelScript. Version 0.1 only took me a few hours to put together as well, it supported integer and float types with basic math operators. The basics of compilers and virtual machines are really quite simple.

If you plan on using your own script language and improve upon it as you go, you'd do well starting on some automated regression test framework already. I use my test_feature for that. Everytime I develop a new feature or encounter a bug I add a scenario that reproduces this to the test_feature project so that I can be sure that this won't be broken with future changes.