Brendan Eich wrote:
> Why do you want it exposed in the language? If for Narcissus in the
> browser, e.g., could you try to do without it? The result won't comply
> with ECMA-262, but should work ok.
That's right, I'm toying with Narcissus. I've just begun working on a
liveprogramming environment where the AST gets transformed by the
programmer in runtime, blending the editor, compiler/interpreter and
debugger into one from the user perspective. I've only looked into
Narcissus for a few days but so far it seems to fit my purpose very well
(with added code for AST modifications in the parser and tracing in the
evaluator). Narcissus tinyness helps me dramatically, compared to
hooking into SpiderMonkey or Rhino (I have no experience in either of
them). It's an elegant piece of code you've written, kudos for that.
My initial idea was to target the browser as a platform for the
liveprogramming environment. Having it running (ECMA-262 compatible) on
a vanilla Firefox would obviously be helpful, but it's not a show-stopper.
For now I just took the short route of removing snarf from global and
hacking
Object.prototype.__defineProperty__ = function(property, value) {
this[property] = value;
}
which is ok for now. Could it be worked around in Narcissus in a proper
way by writing an own (more explicit) property-mechanism that handles
permanent, readonly and enumerate flags on the higher Narcissus-level? I
do realise that the problems would still exist when code interacts
between Narcissus- and SpiderMonkey-boundaries.
Thanks,
Olov Johansson
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine
