rVM

Title *

SummarySome awesome new features will be introduced in the next release (and are partially in the current SVN)

Description *Okay obviously there was not release of rVM lately, that is not cause I am lazy so - OK admitted a very tiny bit of laziness comes in here. But honestly, the next release of RVM will come with some pretty heafty and petty neat new features. h2. ECMA Script Also known as Java Script. It will not be a complete implementation but covering enough to make it useful. Hence the version currently in the svn trunk is already useful. I think this will be pretty awesome as it makes rVM actually useful or at least more useful then a VM that lets you include a brainfuck interpreter in your programs :P. Along with this I will publish a simple example how to load libraries written in rVM compiled languages - meaning you will not only have a way to to share functions of your program with the code of the VM, but you allso will be able to use functions written in the VM. A little test for that is already working pretty well. As another good news, the ECMA Script compiler is developed using RACC, which in other words means you'll get an example on how to make your own compilers. h3. The following features I want to see: * Language structures as loops, conditions and the lik * Prototypes / Objects * Basic data types * Advanced data types as arrays * Exceptopions might *not* be supported. h2. Objects Ah yes the lovely topic, objects objects objects. Everything is object oriented today, the new toaster I got the other day was programmed in OOP! Well so Object Orientation will come to rVM. I've debated about this quite some time, well for me some time - it was just one day - and I decided to make Objects and Classes handled by the VM and not the language compiling them. That means there will be variables of the class Class (or however it end up named) and the class Object (same about the name) those will hold information as parenting chains, variables methods and so on. I will use a message based system equivalent to Objective-C and Ruby, for most part as I really like how they handle thing. h3. Cons A language using the provided object Model might not give a 100% native feel. As say C++ just handles objects completely different and hacks would not work (save for the fact that you still would have a fun time to implement a forceful static language). Another problem that might arias is when a language is not more strict but more free then what the objects provide, admitted I can't think of an example here but there might be. h3. Pros I believe they make up for all the Con's listed above. For once, if wished no one will stop people to write their compilers with a custom implementation of Objects so the alternative is still open. Then, wile currently not a concern, a native implementation will most likely speed Objects up beyond what would have been possible in a custom implementation. It is just a guess but I'd say the speed increase is something between 2 and 5 times faster depending how complex the object model is, perhaps even more. One of the two main reasons for the decision was that, this way other native objects easily can act as objects without the need of importing definitions into every environment, which will ease a lot on memory usage I guess. And a lot on the nerves of those implementing languages. Finally and perhaps most important. Native objects are language independent! As they are handled by the VM it does not matter for the program how they are stored, how to get the methods, parents, and so on. This means I can very well write a objects in ECMA Script, then use it in brainfuck after extending a few methods with the Math Compiler - as while the syntax might differ the underlaying VM code will not. I really really hope this will be useful to some people :P beside me that is. Feedback is very much appriciated.