As a long fan of the LPC language, I thought to put effort into making it a serious contender to create robust and stable applications for any and all uses.

At some point I'll be releasing it open-source but it still needs a lot doing, as I don't want too many people to start using it as I want to reserve the possibility to drastically change some things (for example considering using name-spaces, and the extension-api is still under construction).

In any case for anyone interested, you might consider this an alpha test-release.

It's very stable and very memory-leak-free already - the longest run for a driver has been over four months with constant load on it as a Dropbox-app replacement experiment.

Here's a short goal/feature list (not all are implemented 100% yet, obviously):

Goals/Features:-

* Compiles LPC into as efficient native code as possible on the fly. * As dynamic and flexible as interpreted byte-code languages. * Runs on Win32, Linux, OS X and iPhone OS. * On x86 platforms, creates realtime assembler code using libtcc. * Supports re-compiling objects including updating clones on the fly. * Supports inheriting and function-overriding. * Supports distributing objects across GDs on same machine or network. * Serializing and restoring state. * Safe (crash-proof) threading support. * Native integers (64-bit) and floating points. * Very efficient and fast memory management. * Internally shared strings, arrays, mappings. * Very easy to use networking. * Easy and efficient RPC for powerful object-oriented networking. * Extremely object oriented. * As crash-proof as possible. * Broad set of good functions for various tasks. * Can utilize all libraries/modules made for PHP and other systems. * Also compiles PHP code with little modification. * 2D/3D embedded library and support. * Native GUI widget support. * Good libraries and codebases for both client and server apps and games. * Easily extendable. * To be used for both small script-type shell-processes and heavy applications. * Can be compiled in as a library to other programs. * Built-in sandboxing support. * Will be released as open-source in due course. * Included extensions: OpenSSL, MySQL, SQLite3, Irrlicht, Irrklang.

I still haven't made any decisions and would like opinions and suggestions about whether people would like namespaces such as used in Python etc., or the more usual straight-forward prefixing of function names like mysql_xxx used in old LPC drivers and for example PHP.

The goal is to make extending and linking other API's to it as simple as possible.

In any case, feedback is appreciated and if someone wants to collaborate and join the effort, that'll be welcome too.

I don't know about when to expect to release it, because I work on it as a spare change type of project.

Right now I motivate myself to do it by striving to apply it to real world work applications.

That way I have to make sure it's reliable and supports what's necessary.

It's rather sporadic and gets developed on a need-basis.

I really just don't want to make it a trap for anyone to start using it, or more specifically developing any extensions for it, and then do major changes.

Regarding backwards compatibility, one obvious way it's currently incompatible is that strings, arrays and mappings are initialized to "", ({ }) and ([ ]) respectively.

That could however be made a trivial configuration issue for running legacy code.

Everything being initialized to 0 always bothered me as it results in rather unnecessary initializations that need to be done by the coder, often also causing headache to beginners.

I really want to do the extension-side as perfect as possible before releasing, so that it's easy for others to contribute.

Seeing how utterly awful it is to create extensions (which I've done) in PHP, Perl and Python, and some other platforms including LPC drivers, I want to do it right from the start.

A realistic goal would be to release it at the end of this year, even though I hope it'd happen sooner.

Regarding other compatibilities, I don't bother thinking about it too much at this point.

I've spent some time doing fixes and other admin-tool projects on an LDMud to keep the LPC usage from going rusty over the years.

That's the dialect I've been pretty much following for this.

I used to run DGD a long time ago but don't remember anymore if it had a drastically different dialect.

Not being a fan of lambdas, I haven't implemented them. The ( : : ) (wants to get transformed into a smiley) notation is still my plan for creating inline functions and is rather trivial too but I just haven't needed it yet.