[JarrettBillingsley]

Added/Removed

• Added a require() function to the baselib. It's like a dynamic import; you pass it a string of the module you want to import, and it imports it using the same mechanism as the import statement. Unlike the import statement, it can be used anywhere (since it's just a function call), and you can dynamically build up names to import. This can also be used in interactive mode in MDCL, whereas import cannot.
  
• Added a loadString() function to the baselib. This will take a string containing MiniD code (a list of statements), compile it into a function, and return that new closure. Of course, if there's a compilation error, it'll throw an exception.
  
• Added an eval() function to the baselib. This will take a string containing an expression, compile it, run it, and return the result. There are some restrictions, though; you can't access locals or upvalues around where eval() is called, only globals.
  
• Added MDState.environment(), to get the environment of the current function or of any function on the call stack.
  
• Added a baselib loadJSON() function to load JSON data. It's a JSON parser based on the MiniD compiler, so it's a secure way to load JSON data. All the JSON constructs map directly into their MiniD equivalents, and the function returns the top-level value (either an object or an array).

Changed

• regexp.replace() may now take a function as its replacement parameter. The function takes an instance of the Regexp class and should return a string. This allows for more flexible replacements.
  
• Several speed improvements, including the introduction of MoveLocal and LoadConst instructions for the most common kinds of transfers, tightening up of the interpreter loop, and a new custom hash table implementation for MDNamespace which improves lookup speed and duplication speed (which helps with class instantiations).

Fixed

• MDCL will now execute all statements if you enter multiple statements before hitting enter.

The JSON stuff was just kind of for fun. I saw JSON mentioned on some site and thought "oh yeah, Chris suggested that." So I spent all of 20 minutes and put it into the compiler / baselib.

I've also improved the speed by a bit. I did a lot of tightening up of the interpreter loop, removing unnecessary function calls and simplifying some stuff. You'd be surprised at how much of an improvement just moving the declarations of three MDValues out of the interpreter loop gave.

[csauls]

Pardon me while I do a little dance. MiniD is starting to look every bit as compelling as its big brother.
_________________
Chris Nicholson-Sauls

[r.lph50]

All awesome!

Are there any plans for a toJSON()?

[JarrettBillingsley]

[r.lph50]

I couldn't trace it through the code, but is MiniD allocating a MDValue for every boolean value? Would doing what you have done for nullValue (i.e. having only one global instance) for true and false have any effect?

[JarrettBillingsley]

Well unlike Python, value types (null, bool, int, float, char) are not allocated on the heap. So all locals, members of arrays etc. are MDValues, which are 16-byte structs (they were 8-byte until I made floats double-precision.. because of padding, it's rounded up to 16). Assigning a bool into an MDValue just causes its tag and value to be updated.

The MDValue.nullValue is really only used as a return value from functions which need to return an MDValue*, but have nothing to return. Of course, some other functions return a true null pointer.

[r.lph50]

Aah. I get it now. Other VMs would be referring to the equivalent of MDValue through pointers or reference types.

I keep trying to thing of stuff you haven't covered Albeit it unsuccessfully..

Oh - one question, is the result of serialization intended to work across systems with different endians?

[JarrettBillingsley]