SimpleScript, Part Zero

I’m going to embark upon something ambitious here.  I got an email from Mike, our friendly support engineer on the east coast with the subject line “Need lots of info“.  Apparently he was contacted by a customer who wants to implement a new script engine that supports debugging, and, here’s the part that you’ve got to really grit your teeth over: in C#. 

My initial response was, of course, “They’re crazy — talk them out of it!”  Not to put too fine a point on it, that’s an immense amount of work in any language.  But C#? The script interfaces were designed long, long before there was managed code.  It’s quite likely that it’s going to be very hard to write a straightforward interop layer for those interfaces.  “Could they use the managed IVsa interfaces instead?” I asked Mike.

I haven’t heard back yet, but I got to thinking last night that maybe it would be interesting to develop a script engine from scratch, describing every interface as I implement it, giving some of the design history behind the interfaces, etc, etc, etc.  I could start it in C++ and then see whether there were ways to make it work well in managed code, etc.

I could then blog a little bit of the code every few days.  This would keep me in blog topics for weeks, certainly.  Probably months.  All of this stuff happens in my spare time, and I have precious little of that, particularly given the number of bugs I have to fix before the Whidbey beta.  But I’ll see what I can do.

I’m not sure that a piecemeal daily blog approach is even the right way to handle this kind of material, but I’m willing to make the experiment. 

This is probably how it will go:

Phase One: Basic Infrastructure
-       dll entrypoints
-       registration
-       class factory
-       engine skeleton

Phase Two: Building the engine
-       script engines as state machines
-       threading concerns
-       named items
-       event handling

Phase Three: Processing the language
-       grammar
-       lexer
-       parser
-       code generator
-       interpreter
-       runtime library

Phase Four: Debugger support
-       breakpoints
-       evaluation
-       syntax colouring
-       context

Phase Five: Managed Code
-       ?

That’s just off the top of my head.  We’ll probably mix it up a bit as we go.

Comments (10)

  1. John Stanhope says:

    I would love to see such a series. I have messed around with the ActiveScript interfaces a little and there seems to be alot of good stuff their but it is very minimally documented.

  2. Dan Shappir says:

    Way to go man! I’d love for you to do this.

  3. Danny says:

    I’m looking forward to this!

    One thought – if you’re describing cleanly from interfaces, shouldn’t it be possible to do it in such a way as to lead to an implementation in C++/C#/Java/Smalltalk or whatever?

  4. Alex Angelopoulos says:


    As you go, could you try providing definitions for scripters of some of the concepts above? Armwavy ones would actually be excellent. (I know, this isn’t TARGETED at scripters per se, but every scripter wants to do more and this is already a thousand times more readable than the MSDN docs on script engines).

    Concepts of particular value since they crop up but people don’t know what they mean clearly:

    class factory

    state machine

    event handling – that IS covered in some understandable detail…

    grammars: only a small proportion of Windows developers seems to know much about this. The curse of an easy development environment. ;)

    lexing/parsing and how they relate to each other.

    Runtime library (and the distinction between that and the language itself).

    That might all be something to go into a separate blog item – "Eric Lippert’s Dragon Blog" or something like that. ;)

  5. Eric Lippert says:

    Sure — as you can see in Part Two I give justification for the class factory architecture, etc. I’ll certainly describe the rationales behind design decisions and give examples of pitfalls in the implementations as I go.

  6. Hugh Brown says:


    Before I get into it, a Lambda poster pointed me at the NullScript project, which is a very interesting illustration of how reverse engineering works. It’s an implementation of a "null" script engine — an engine with no language — in ATL, which the intrepid developer created in order to try and understand how ASP works. Typical programmer! They could have just asked me, but where’s the fun in that?


    The article you cite is dated 2003-09-18. I assume that that is approximately the date it was published. NullScript was written from 2001-04-10 to 2001-05-10, a full two years before your article. It’s a bit unfair to comment that I did not refer to an article that I believe did not yet exist.


  7. bram van kampen says:


    Loads of interesting stuff. No Links thoug to jump from blog to blog, (i.e. Next Chapter)