Thursday, 16 June 2011

C++ and interpreted languages

Let's take a look at interpreted languages, shall we? In this case, I'm going to limit the context to interpreted languages being used to extend a host program, or whose explicit use is to extend a host program- so we can skip something like PHP, which is usually used on it's own. For example, Lua, is definitely covered- and I have quite a bit of experience with Lua, so I'll mostly pull examples there.

Why on earth would you make such a language dynamic? By this, I'm talking about the usual waft of dynamic language features- dynamic typing, garbage collection, etc.

How the hell is anyone supposed to find it easy to communicate between two languages with completely separate paradigms? If you're going to design Language A to be used to extend Language B, then pretty logically, the core point here is extend. That means that Language A should probably be quite similar to Language B, to make the extension easier.

Instead, all of the extension languages like JavaScript, Lua, and (to a lesser extent) Python, are ridiculously dynamic.

If you have a C++ application, why do you embed Lua? Because you want to interpret the code at run-time. If not for that, you would never use Lua. Why should the need to interpret the code at run-time necessarily imply that we also need to imply a bunch of other things at run-time (instead of at interpret-time)? Having dynamic types just makes life much harder for the extender.

I think that a language which is intended to be used to extend a statically typed, high-performance language should be statically-typed, high-performance. Indeed, with the magic of templates, then you can extend a mythical ideal extension language's type system from C++ to include whatever C++ types you need- if you like virtual functions.

Then, instead of having to waste your life marshalling them and stuff, it could  just work. If I want to marshal shared_ptr<int> then- well, my extension language already has that type, so it just goes. I know in advance that C++ types tend to depend on constructors and deterministic destruction, so I'll write my language to respect that automatically. I know that my C++ application, which I am extending, will use value types- as that's the C++ system- so I will write a value-typed script language. This will make all of my C++ types cleanly and easily marshal between languages. In fact, I might even get away with no marshalling whatsoever, and give my script language the apparently incredibly impressive ability to call C++ functions that weren't built explicitly for the sole purpose of interoperation, as long as their return values and arguments are listed types.

And thus, I might be able to create an extension language that can actually do what it's supposed to do - extend.

No comments:

Post a Comment