Right. Technically Mug will conform to the ECMAScript 3 Compact Profile: http://www.ecma-international.org/publications/files/ECMA-ST... Which doesn't include eval() or the with(){} statement (both used infrequently enough that it's not worth the overhead).

A REPL would still be possible, however, it would require some work to maintain the current scope between input.

Is there a reason you are not targeting ECMA5 (with the exclusions you mentioned)?

Much of the runtime has been developing by trying out existing code, then adding support gradually. Of course most of the code I tried out was ECMA3 compliant.

I expect to add in support for ECMAScript 5's Object extensions API (defineProperty, getters/setters) as Mug supports them internally, just as Mug already has a global JSON object. The features which could cause incompatibility with existing code is something I'd have to consider separately, so it depends when a majority of authors start writing ECMA5-compliant code (no function.callee, implicit this object bound to global, etc.)

Right, right, but then how useful would Mug be if the dynamic stuff in JS can't be used?

Munging strings and then eval()ing them is the worst way to write dynamic code. Hopefully its not common in most js libraries.

Missing eval() is a feature.

As a follow up in case anyone is curious about the why behind this assertion, consider a line of code like this

    eval("myObject."+functionName+"()")

Not only does it make it difficult to track down the calls to this method, it is now impossible to minify this chunk of code, something that is very commonly done in javascript. This is why javascript includes things like apply() and accessing members of an object in multiple ways (obj.attribute == obj['attribute'], for user-defined values of attribute).

The "dynamic stuff" appears to all be included. Just not eval(), which is probably a bad thing for most JS code anyway...