Jurassic is an exceptionally easy runtime to interface with. You have to create a script engine, assign it some global variables or functions if you like, and then tell it to execute script. Very, very easy. In fact, it took me about an hour to drum up a fairly comprehensive script plugin for JinxBot, which is able to respond to all of BN#’s events (except the clan ones).
I have several goals and some things I’ve already contributed to the Jurassic source:
Some things that I’ve already started working on and would like to see accomplished:
- Create a console-based REPL loop.
- Create a standard library to allow for sandboxed lower-level I/O. To account for this, I’m planning to add an import(package, [assembly = ‘Jurassic.Library’], [alias]) function to the global object. For example, import(‘Jurassic.Library.Io’); would import the I/O library, which would enable construction of objects like new io.ByteStream().
- Create events on ScriptEngine that would allow the engine’s host to intercept, handle, and debug scripting errors. The biggest use-case I see here is, for example, the debugger statement. The goal I have here is to be able to create your own debugger, instead of having to launch the system JScript debugger, especially since the JScript debugger is ignorant of the scope and other objects within Jurassic’s engine.
- Another event I’d like to be able to add is something like EngineAppearsToCycle. Someone made the point that you could go into the console and type while (true) console.log(‘’) and crash your browser. The compiler could be refactored somewhat to enable this to be handled.
Eventually, I think it would be cool to refactor the compilation engine to function more like V8 – specifically with its metaclasses. I’m not particularly adept at building a lexer or parser, but I think Paul has already done a great job, and the engine is still quite fast. Consequently, this is more of a long-term because-I-can goal than we-need-to-do-it goal, because I honestly don’t think it needs to be done.