Though I admire the goals you have, you seem to have ignored the fact that the key feature of most dynamic-language VMs is that an object's fields (aka member variables) are typically not known (or knowable) ahead of time. Fields can be added on the fly; typically, no space is taken for a field in an object instance until a value is assigned to the field. In most dynamic languages, fields can be removed, and their types can be changed in a way that would change the space needed to store the value. It is not particularly abnormal for different instances of the same class to have different fields. There is no real possibility of laying out the raw values the way they would be in a compiled C program without severely restricting the "dynamicness" available to the developer. (Even if you made the rule that the class defn prescribes the list of members of each class instance, as mentioned in the next paragraph, you couldn't readily handle the class defn changing while the program is running -- something that is commonly possible [and definitely desirable] in dynamic languages.)
There is a feature in Python that lets a class author announce that there won't be any changes to the list of members, so that each instance (rather than having a list of [name, value] pairs defining the members) can leave out the list of names and hold only the values of the members. (The goal was to let things like an array of 100,000 "points" not take up a lot more space than the 200,000 values that are the X and Y coordinates.) However, the defined members in that case don't have to be simple values -- they could be (pointers to) other Python objects.) You'd have a better chance of having something interoperable if you defined a "universal" format for the list of [name, value] pairs that are typically used to describe object instances in dynamic languages. You could then have a library that could read from each target VM into your universal format, and write from your format to each target VM. But you're not going to get "the speed of C" when part of the game is to look up names all the time. (That cost is something that those of us who like dynamic languages feel is sufficiently low compared to what we get in return.) Good luck... J. Merrill From: Shelby Moore <[email protected]> To: [email protected] Date: 01/19/2010 04:23 AM Subject: [Neko] Enabling 80/20 programming language interoperability? Sent by: <[email protected]> Perhaps I should have entitled this, "Binary interoperable data types application virtual machine?" [snip]
-- Neko : One VM to run them all (http://nekovm.org)
