Tue, 7 Jan 2003 12:53:36 -0000
I was thinking maybe we could implement a switch in the compiler so that
code will compile to either ECMA 3, 4 or Jscript.NET depending on the
From: Steve Newman [mailto:firstname.lastname@example.org]
Sent: 06 January 2003 23:02
Cc: Jeroen Janssen
At 23:02:08 +0100 1/6/03, Jeroen Janssen <email@example.com> wrote:
>Andrew Stopford wrote:
>>Steve thanks for the license info and for sorting those notes out :)
Another question that has sprung to mind is what is the end goal of the
compiler, to be compatible wih JScript.NET or compatible with ECMA 3,
obviously JScript.NET is (almost) compliant with ECMA 3 but do we intend
to be closer to that mark?
>There is an ECMA/non ECMA 'chapter', which I think contains interesting
>information for us.
Thanks, this link is a big help. Here's a quote:
>JScript .NET incorporates almost all of the features in ECMAScript
Edition 3 and many of the proposed features proposed for ECMAScript
Edition 4. In addition, JScript also has many unique features that are
not provided by the ECMAScript languages. These JScript .NET specific
features are listed in the table below.
I interpret this as follows:
* The language that Microsoft has implemented is "almost" a strict
superset of ECMAScript 3, i.e. they've implemented ECMAScript 3 except
for a few corner cases.
* They've added some additional functionality.
* Some, but not all, of the additional functionality may appear as part
of a forthcoming "ECMAScript 4" specification.
So, in the big picture, there are several questions to be resolved under
the heading of "which language should we implement":
1. In the areas where JScript.NET is not compliant with ECMAScript 3
(other than the addition of new features), do we follow JScript.NET or
ECMAScript 3? It's hard to answer this without knowing what the
differences are. I didn't find a list in my (so far) brief glance at
the Microsoft site.
I would like to believe that the differences are minor, and consist of
corner cases which the JScript team simply didn't bother to implement.
If so, my vote would be to follow ECMAScript 3, since there is a
thorough, stable specification document for that language.
If there are differences that could break real-world JScript code, we
would have to reconsider. Ultimately we might try to support both (with
a mode switch of some sort).
Does anyone know exactly where JScript.NET deviates from ECMAScript?
2. Presumably, we should aim to implement all of the features that
JSCript.NET has added "above and beyond" ECMAScript 3, as described in
the link mentioned above.
If the Microsoft documentation is not sufficiently rigorous, we might
consider creating our own specification document.
3. As the ECMAScript 4 standard solidifies, if its specification for the
new features deviates from JScript.NET, we would have a dilemma. I
would lean toward matching JScript.NET, at least initially, since that's
what real code is using.
In the long run, if ECMAScript 4 is finalized in a form inconsistent
with JScript.NET, we might want to support both. We can cross that
bridge when we come to it.
4. ECMAScript 4 includes more than just Microsoft's JScript.NET
extensions. It's a pretty ambitious proposal. See this page:
Ultimately, it might be interesting to implement all of the ECMAScript 4
extensions. But I would prioritize this well below the tasks that have
already been discussed, such as JScript.NET support, direct IL code
generation, a proper command-line tool, and CodeDom support.
Mono-list maillist - Monofirstname.lastname@example.org