The original goals of this proposal were
If the implementation cannot produce a source code string that meets these criteria then it must return a string for whicheval
will throw aSyntaxError exception.
The goals were later revised to include
The goals were revised again to include
toString
must return source text slice from beginning of first token to end of last token matched by the appropriate grammar production
toString
must not return anything other than toString
must return toString
must synthesise a source text
toString
must throw a The goals were revised yet again to include
The specification often uses a numbered list to specify steps in an algorithm. These algorithms are used to precisely specify the required semantics of ECMAScript language constructs. The algorithms are not intended to imply the use of any specific implementation technique. In practice, there may be more efficient algorithms available to implement a given feature.
Algorithms may be explicitly parameterized, in which case the names and usage of the parameters must be provided as part of the algorithm's definition. In order to facilitate their use in multiple parts of this specification, some algorithms, called abstract operations, are named and written in parameterized functional form so that they may be referenced by name from within other algorithms. Abstract operations are typically referenced using a functional application style such as operationName(arg1, arg2). Some abstract operations are treated as polymorphically dispatched methods of class-like specification abstractions. Such method-like abstract operations are typically referenced using a method application style such as someValue.operationName(arg1, arg2).
Calls to abstract operations return ?
indicate that
The prefix !
is used to indicate that an abstract operation will never return an
Algorithms may be associated with productions of one of the ECMAScript grammars. A production that has multiple alternative definitions will typically have a distinct algorithm for each alternative. When an algorithm is associated with a grammar production, it may reference the terminal and nonterminal symbols of the production alternative as if they were parameters of the algorithm. When used in this manner, nonterminal symbols refer to the actual alternative definition that is matched when parsing the source text. The source text matched by a grammar production is the portion of the source text that starts at the beginning of the first terminal that participated in the match and ends at the end of the last terminal that participated in the match.
When an algorithm is associated with a production alternative, the alternative is typically shown without any “[ ]” grammar annotations. Such annotations should only affect the syntactic recognition of the alternative and have no effect on the associated semantics for the alternative.
Unless explicitly specified otherwise, all chain productions have an implicit definition for every algorithm that might be applied to that production's left-hand side nonterminal. The implicit definition simply reapplies the same algorithm name with the same parameters, if any, to the
but there is no corresponding Evaluation algorithm that is explicitly specified for that production. If in some algorithm there is a statement of the form: “Return the result of evaluating
Runtime Semantics: Evaluation
For clarity of expression, algorithm steps may be subdivided into sequential substeps. Substeps are indented and may themselves be further divided into indented substeps. Outline numbering conventions are used to identify substeps with the first level of substeps labelled with lower case alphabetic characters and the second level of substeps labelled with lower case roman numerals. If more than three levels are required these rules repeat with the fourth level using numeric labels. For example:
A step or substep may be written as an “if” predicate that conditions its substeps. In this case, the substeps are only applied if the predicate is true. If a step or substep begins with the word “else”, it is a predicate that is the negation of the preceding “if” predicate step at the same level.
A step may specify the iterative application of its substeps.
A step that begins with “Assert:” asserts an invariant condition of its algorithm. Such assertions are used to make explicit algorithmic invariants that would otherwise be implicit. Such assertions add no additional semantic requirements and hence need not be checked by an implementation. They are used simply to clarify algorithms.
Mathematical operations such as addition, subtraction, negation, multiplication, division, and the mathematical functions defined later in this clause should always be understood as computing exact mathematical results on mathematical real numbers, which unless otherwise noted do not include infinities and do not include a negative zero that is distinguished from positive zero. Algorithms in this standard that model floating-point arithmetic include explicit steps, where necessary, to handle infinities and signed zero and to perform rounding. If a mathematical operation or function is applied to a floating-point number, it should be understood as being applied to the exact mathematical value represented by that floating-point number; such a floating-point number must be finite, and if it is
The mathematical function
The mathematical function
The notation “
The mathematical function
ECMAScript function objects encapsulate parameterized ECMAScript code closed over a lexical environment and support the dynamic evaluation of that code. An ECMAScript function object is an ordinary object and has the same internal slots and the same internal methods as other ordinary objects. The code of an ECMAScript function object may be either
ECMAScript function objects have the additional internal slots listed in
Internal Slot | Type | Description |
---|---|---|
[[Environment]] | The | |
[[FormalParameters]] | Parse Node | The root parse node of the source text that defines the function's formal parameter list. |
[[FunctionKind]] | String | Either "normal" , "classConstructor" or "generator" . |
[[ECMAScriptCode]] | Parse Node | The root parse node of the source text that defines the function's body. |
[[ConstructorKind]] | String | Either "base" or "derived" . |
[[Realm]] | The | |
[[ScriptOrModule]] | The script or module in which the function was created. | |
[[ThisMode]] | (lexical, strict, global) | Defines how this references are interpreted within the formal parameters and code body of the function. this refers to the |
[[Strict]] | Boolean | |
[[HomeObject]] | Object | If the function uses super , this is the object whose [[GetPrototypeOf]] provides the object where super property lookups begin. |
[[SourceText]] | String | The |
All ECMAScript function objects have the [[Call]] internal method defined here. ECMAScript functions that are also constructors in addition have the [[Construct]] internal method.
With parameter scope.
"default"
).An anonymous export default
declaration.
An alternative semantics is provided in
The
A prototype
property is automatically created for every function defined using a
An arguments
, super
, this
, or new.target
. Any reference to arguments
, super
, this
, or new.target
within an super
, the function object created in step 4 is not made into a method by performing super
is always contained within a non-super
is accessible via the scope that is captured by the function object of the
With parameters object and optional parameter functionPrototype.
With parameters object and enumerable.
See
"get"
)."set"
).With parameter scope.
"prototype"
, PropertyDescriptor{[[Value]]: prototype, [[Writable]]: "prototype"
, PropertyDescriptor{[[Value]]: prototype, [[Writable]]: "default"
).An anonymous export default
declaration.
With parameter object and enumerable.
"prototype"
, PropertyDescriptor{[[Value]]: prototype, [[Writable]]: "prototype"
, PropertyDescriptor{[[Value]]: prototype, [[Writable]]: "prototype"
, PropertyDescriptor{[[Value]]: prototype, [[Writable]]: The
With parameter scope.
"prototype"
, PropertyDescriptor{[[Value]]: prototype, [[Writable]]: "prototype"
, PropertyDescriptor{[[Value]]: prototype, [[Writable]]: "default"
).An anonymous export default
declaration.
With parameter object and enumerable.
"prototype"
, PropertyDescriptor{[[Value]]: prototype, [[Writable]]: "prototype"
, PropertyDescriptor{[[Value]]: prototype, [[Writable]]: "prototype"
, PropertyDescriptor{[[Value]]: prototype, [[Writable]]: The
"name"
)."name"
).If the class definition included a name
static method then that method is not over-written with a name
data property for the class name.
With parameter scope.
"default"
).With parameters object and enumerable.
The abstract operation CreateDynamicFunction is called with arguments constructor, newTarget, kind, and args. constructor is the constructor function that is performing this action, newTarget is the constructor that new
was initially applied to, kind is either "normal"
, "generator"
, or "async"
, and args is a
"normal"
, then"%FunctionPrototype%"
."generator"
, then"%Generator%"
."async"
."%AsyncFunctionPrototype%"
.","
(a comma), and nextArgString."generator"
, then"async"
, then"generator"
, then"prototype"
, PropertyDescriptor{[[Value]]: prototype, [[Writable]]: "normal"
, perform "prototype"
property."anonymous"
)." anonymous("
, the code units of P, 0x000A (LINE FEED), the code units of ") {"
, 0x000A (LINE FEED), the code units of bodyText, 0x000A (LINE FEED), and the code units of "}"
.A prototype
property is automatically created for every function created using CreateDynamicFunction, to provide for the possibility that the function will be used as a constructor.
Kind | Prefix |
---|---|
"normal" | "function" |
"generator" | "function*" |
"async" | "async function" |
"async generator" | "async function*" |
HostHasSourceTextAvailable is an implementation-defined abstract operation that allows host environments to prevent the source text from being provided for a given function.
An implementation of HostHasSourceTextAvailable must complete normally in all cases. This operation must be idempotent. Each time it is called with a specific func as its argument, it must return the same completion record. The default implementation of HostHasSourceTextAvailable is to unconditionally return a normal completion with a value of
When the toString
method is called with an object func as its
toString
Representation Requirements:
eval
in a lexical context that is equivalent to the lexical context used to create the original object, it will result in a new functionally equivalent object. In that case the returned source code must not mention freely any variables that were not mentioned freely by the original function's source code, even if these “extra” names were originally in scope.
eval
will throw a © 2018 Michael Ficarra
All Software contained in this document ("Software") is protected by copyright and is being made available under the "BSD License", included below. This Software may be subject to third party rights (rights from parties other than Ecma International), including patent rights, and no licenses under such third party rights are granted under this license even if the third party concerned is a member of Ecma International. SEE THE ECMA CODE OF CONDUCT IN PATENT MATTERS AVAILABLE AT http://www.ecma-international.org/memento/codeofconduct.htm FOR INFORMATION REGARDING THE LICENSING OF PATENT CLAIMS THAT ARE REQUIRED TO IMPLEMENT ECMA INTERNATIONAL STANDARDS.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
THIS SOFTWARE IS PROVIDED BY THE ECMA INTERNATIONAL "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL ECMA INTERNATIONAL BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.