Christopher Allen

@Webifi: to try to answer some of your specific questions: > Any pointers on how to build a valid Interpreter.State from a Function object passed to a native function, and...

> cache invalidation and naming things... Ugh yes, so true. > I've used "pseudo function" to refer to both interpreted functions and native functions wrapped in a FUNCTION_PROTO. I'm uncertain...

> I've been using "pseudo function", but perhaps that too confusing? Absent any clear precedent I think that is absolutely fine.

I'm not clear on how to contact the person who currently owns the `js-interpreter` npm package, nor whether they would be willing and able to transfer it, but I would...

I'm on annual leave at the moment but will look at this when I get back to the office. Thanks @tjenkinson for the PR and @mercmobily for offering the use...

Thanks for taking matters in to your own hands, @hsluoyz, but I'm going to reopen this as I concur that there should be an official package.

This is a good observation. The original JS Interpreter use-case envisaged that there would always be some external supervisory code responsible for calling `.step()` (or, less usually, `.run()`—see for example...

Note to anyone tackling this bug: `.step` probably needs to be split into a wrapper that does the reentrancy check and an implementation (which can also be called from `.run`)...

It's unclear what the best way to proceed is. Async implementations that accept variable numbers of arguments should previously have been using `Array.prototype.pop.call(arguments)` to obtain `callback`; they are currently broken...

@pakya-1909: Thanks for the offer. I think this issue is waiting for @NeilFraser to make a decision about whether he is willing to break backwards compatibility to fix varargs or...