5 | title: Function.prototype.toString revision 6 | status: proposal 7 | stage: 4 8 | contributors: Michael Ficarra 9 | location: https://github.com/tc39/Function-prototype-toString-revision 10 |11 | 12 | 13 |
The original goals of this proposal were
18 | 19 |23 | If the implementation cannot produce a source code string that meets these criteria then it must return a string for which `eval` will throw a *SyntaxError* exception. 24 |25 |
The goals were later revised to include
31 | 32 |The goals were revised again to include
37 | 38 |The goals were revised yet again to include
47 | 48 |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.
58 |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_).
59 |Calls to abstract operations return Completion Records. Abstract operations referenced using the functional application style and the method application style that are prefixed by `?` indicate that ReturnIfAbrupt should be applied to the resulting Completion Record. For example, ? operationName() is equivalent to ReturnIfAbrupt(operationName()). Similarly, ? _someValue_.operationName() is equivalent to ReturnIfAbrupt(_someValue_.operationName()).
60 |The prefix `!` is used to indicate that an abstract operation will never return an abrupt completion and that the resulting Completion Record's value field should be used in place of the return value of the operation. For example, “Let _val_ be ! operationName()” is equivalent to the following algorithm steps:
61 |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.
67 |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.
68 |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 chain production's sole right-hand side nonterminal and then returns the result. For example, assume there is a production:
69 |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 |Block|” it is implicit that an Evaluation algorithm exists of the form:
74 |Runtime Semantics: Evaluation
75 |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:
80 |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.
90 |A step may specify the iterative application of its substeps.
91 |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.
92 |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 *+0* or *-0* then the corresponding mathematical value is simply 0.
93 |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 strict mode code (
ECMAScript function objects have the additional internal slots listed in
| Internal Slot | Type | Description |
|---|---|---|
| [[Environment]] | Lexical Environment | The Lexical Environment that the function was closed over. Used as the outer environment when evaluating the code of the function. |
| [[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]] | Realm Record | The realm in which the function was created and which provides any intrinsic objects that are accessed when evaluating the function. |
| [[ScriptOrModule]] | Script Record or Module Record | 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. ~lexical~ means that `this` refers to the *this* value of a lexically enclosing function. ~strict~ means that the *this* value is used exactly as provided by an invocation of the function. ~global~ means that a *this* value of *undefined* is interpreted as a reference to the global object. |
| [[Strict]] | Boolean | *true* if this is a strict mode function, *false* if this is not a strict mode function. |
| [[HomeObject]] | Object | If the function uses `super`, this is the object whose [[GetPrototypeOf]] provides the object where `super` property lookups begin. |
| [[SourceText]] | 124 |String | 125 |The |
126 |
All ECMAScript function objects have the [[Call]] internal method defined here. ECMAScript functions that are also constructors in addition have the [[Construct]] internal method.
131 |With parameter _scope_.
138 |An anonymous |FunctionDeclaration| can only occur as part of an `export default` declaration.
160 |An alternative semantics is provided in
The |BindingIdentifier| in a |FunctionExpression| can be referenced from inside the |FunctionExpression|'s |FunctionBody| to allow the function to call itself recursively. However, unlike in a |FunctionDeclaration|, the |BindingIdentifier| in a |FunctionExpression| cannot be referenced from and does not affect the scope enclosing the |FunctionExpression|.
204 |A `prototype` property is automatically created for every function defined using a |FunctionDeclaration| or |FunctionExpression|, to allow for the possibility that the function will be used as a constructor.
207 |An |ArrowFunction| does not define local bindings for `arguments`, `super`, `this`, or `new.target`. Any reference to `arguments`, `super`, `this`, or `new.target` within an |ArrowFunction| must resolve to a binding in a lexically enclosing environment. Typically this will be the Function Environment of an immediately enclosing function. Even though an |ArrowFunction| may contain references to `super`, the function object created in step 4 is not made into a method by performing MakeMethod. An |ArrowFunction| that references `super` is always contained within a non-|ArrowFunction| and the necessary state to implement `super` is accessible via the _scope_ that is captured by the function object of the |ArrowFunction|.
229 |With parameters _object_ and optional parameter _functionPrototype_.
237 |With parameters _object_ and _enumerable_.
256 |See
With parameter _scope_.
301 |An anonymous |GeneratorDeclaration| can only occur as part of an `export default` declaration.
325 |With parameter _object_ and _enumerable_.
333 |The |BindingIdentifier| in a |GeneratorExpression| can be referenced from inside the |GeneratorExpression|'s |FunctionBody| to allow the generator code to call itself recursively. However, unlike in a |GeneratorDeclaration|, the |BindingIdentifier| in a |GeneratorExpression| cannot be referenced from and does not affect the scope enclosing the |GeneratorExpression|.
383 |With parameter _scope_.
391 |An anonymous |AsyncGeneratorDeclaration| can only occur as part of an `export default` declaration.
419 |With parameter _object_ and _enumerable_.
427 |The |BindingIdentifier| in an |AsyncGeneratorExpression| can be referenced from inside the |AsyncGeneratorExpression|'s |AsyncGeneratorBody| to allow the generator code to call itself recursively. However, unlike in an |AsyncGeneratorDeclaration|, the |BindingIdentifier| in an |AsyncGeneratorExpression| cannot be referenced from and does not affect the scope enclosing the |AsyncGeneratorExpression|.
484 |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.
541 |With parameter _scope_.
549 |With parameters _object_ and _enumerable_.
577 |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 List containing the actual argument values that were passed to _constructor_. The following steps are taken:
655 |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.
724 || 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.
743 |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 *true*.
744 |When the `toString` method is called with an object _func_ as its *this* value, the following steps are taken:
752 | 753 |`toString` Representation Requirements:
762 |