572813 - Nonstandard features used in Narcissus JavaScript engine

Status: RESOLVED WONTFIX

(Other Applications Graveyard :: Narcissus, defect)

Description

[Tom Austin]

Currently, Narcissus relies on some nonstandard JavaScript features, outlined here:

*conditional catches -- Easy enough to refactor away
*snarf function -- Can be written in a browser using XHR:
  function snarf(url) {
    var request;
    request = new XMLHttpRequest();
    request.open("GET", url, false);
    request.send(null);
    if (request.status !== 200) {
      throw new Error("Failed to retrieve file: " + request.status);
    }
    return request.responseText;
  }
*__defineProperty__ -- Seems to be the biggest source of problems.  Can be refactored to use Object.defineProperty() instead.
*__defineGetter__ and __defineSetter__ -- Work OK in standard build, but should probably be replaced with Object.defineProperty().
*__proto__ -- Can replace with Object.getPrototypeOf()
*const fields -- Possibly replace with Object.defineProperty().
*Errors with line numbers (specifically TypeError and SyntaxError)
*Callable regexs
*__call__, __hasInstance__, and __construct__ -- Not sure on the role of these yet.

Comment 1

[Brendan Eich [:brendan]]

We should use ES5 everywhere possible. But for cases where ES5 is not enough and our extension is winning, I'd rather stick with the extension.

The goal can't be portability at current level of functionality and integrity, since other implementations (some < ES5) just don't have what Narcissus needs.

/be

Comment 2

[Andreas Gal :gal]

If there is no huge win (i.e. syntactic sugar like catch guards), I would prefer writing portable JS. I was imagining narcissus as a great way to test proxies and interoperability once a 2nd VM implements them.

Comment 3

[Brendan Eich [:brendan]]

(In reply to comment #2)
> If there is no huge win (i.e. syntactic sugar like catch guards),

Those are more than sugar: single catch means you have to write the guards by hand *and* remember to rethrow in a final else, or default: switch case. This is strictly uglier and more error-prone.

/be

Comment 4

[Andreas Gal :gal]

How often is it used? I remember only seeing it once.

Comment 5

[Brendan Eich [:brendan]]

You could find the answer faster than it took us to write two comments here!

$ grep 'catch.* if ' ../narcissus/*.js
../narcissus/jsexec.js:        } catch (e if e == THROW) {
../narcissus/jsexec.js:                        } catch (e if e == BREAK && x.target == n) {
../narcissus/jsexec.js:            } catch (e if e == BREAK && x.target == n) {
../narcissus/jsexec.js:            } catch (e if e == CONTINUE && x.target == n) {
../narcissus/jsexec.js:            } catch (e if e == BREAK && x.target == n) {
../narcissus/jsexec.js:            } catch (e if e == CONTINUE && x.target == n) {
../narcissus/jsexec.js:            } catch (e if e == BREAK && x.target == n) {
../narcissus/jsexec.js:            } catch (e if e == CONTINUE && x.target == n) {
../narcissus/jsexec.js:        } catch (e if e == THROW && (j = n.catchClauses.length)) {
../narcissus/jsexec.js:        } catch (e if e == BREAK && x.target == n) {
../narcissus/jsexec.js:        } catch (e if e == RETURN) {
../narcissus/jsexec.js:        } catch (e if e == THROW) {
../narcissus/jsexec.js:    } catch (e if e == THROW) {

It's important in all these cases to get automatic rethrow on guard failure.

/be

Comment 6

[Jeff Walden [:Waldo]]

(In reply to comment #3)
> Those are more than sugar: single catch means you have to write the guards by
> hand *and* remember to rethrow in a final else, or default: switch case. This
> is strictly uglier and more error-prone.

Maybe I'm missing some wrinkle to the semantics, but isn't that still syntactic sugar?

Comment 7

[Dave Herman [:dherman]]

> Maybe I'm missing some wrinkle to the semantics, but isn't that still syntactic
> sugar?

I think it's syntactic sugar in the sense of "can be defined by a purely local rewriting." It's a fairly delicate one, though. In spirit, people use "syntactic sugar" to mean "you can do the translation in your head." That's arguable here.

Dave

Comment 8

[Brendan Eich [:brendan]]

Narcissus was not intended to conform to existing standards when it was written, since there was no way to do it. More, I wanted it to be smaller and more elegant than the standards support, specifically (among several particulars) by using catch guards. The usability of catch without guards is poor, but then try/catch is not much used for other reasons.

For Harmony, we want a refutable match extension, which Dave points out catch guards prefigure. Probably we can get something equally concise and fool-proof (the automatic rethrow on guard failure) developed and spec'ed.

In the mean time, unless there's both a requirement to run, and a realistic hope of running, Narcissus on other engines, I don't think we should overdo standards for standards' sake. Standards suck.

/be

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Closing as Narcissus isn't maintained anymore.