Mon, 6 Jan 2003 15:02:16 -0800
At 23:02:08 +0100 1/6/03, Jeroen Janssen <firstname.lastname@example.org> 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.