Editorial: Re-word re built-in function implemented as ECMAScript function #3007
Conversation
In the "Built-in Function Objects" section, bring together all the stuff about a built-in function being implemented as an ECMAScript function. (And downplay it by putting it at the bottom of the section.)
In the status quo, a built-in function can be implemented as *either* an ECMAScript function object (with the 10.2.1 [[Call]]) *or* as some other kind of function object (with the 10.3.1 [[Call]]). Instead, this commit says that *all* built-in functions are 10.3.1 functions, but some can *additionally* be 10.2.1 functions, which is possible because 10.2.1 is a specialization of 10.3.1.
|
Or, if you want to eliminate all mention that a built-in function can be implemented as an ECMAScript function, then that's an easy delete after the edits of this PR. |
It doesn't matter that 10.2.1 isn't a specialization of 10.3.1, it only matters that it's possible to conform to both. I've added a fixup to that effect, and taken this PR out of Draft. |
| <p>Built-in function objects that are not identified as constructors do not implement the [[Construct]] internal method unless otherwise specified in the description of a particular function. When a built-in constructor is called as part of a `new` expression the _argumentsList_ parameter of the invoked [[Construct]] internal method provides the values for the built-in constructor's named parameters.</p> | ||
| <p>Built-in functions that are not constructors do not have a *"prototype"* property unless otherwise specified in the description of a particular function.</p> | ||
| <p>If a built-in function object is not implemented as an ECMAScript function it must provide [[Call]] and [[Construct]] internal methods that conform to the following definitions:</p> | ||
| <p>A built-in function object may be implemented as an ECMAScript function object (<emu-xref href="#sec-ecmascript-function-objects"></emu-xref>), where its behaviour is implemented by the ECMAScript code that is the body of the function. In such a case:</p> |
There was a problem hiding this comment.
I definitely want to get rid of this concept of a built-in function implemented as an ECMAScript function.
edit: See #2734.
| <p>Unless otherwise specified every built-in function object has the %Function.prototype% object as the initial value of its [[Prototype]] internal slot.</p> | ||
| <p>The behaviour specified for each built-in function via algorithm steps or other means is the specification of the function body behaviour for both [[Call]] and [[Construct]] invocations of the function. However, [[Construct]] invocation is not supported by all built-in functions. For each built-in function, when invoked with [[Call]], the [[Call]] _thisArgument_ provides the *this* value, the [[Call]] _argumentsList_ provides the named parameters, and the NewTarget value is *undefined*. When invoked with [[Construct]], the *this* value is uninitialized, the [[Construct]] _argumentsList_ provides the named parameters, and the [[Construct]] _newTarget_ parameter provides the NewTarget value. If the built-in function is implemented as an ECMAScript function object then this specified behaviour must be implemented by the ECMAScript code that is the body of the function. Built-in functions that are ECMAScript function objects must be strict functions. If a built-in constructor has any [[Call]] behaviour other than throwing a *TypeError* exception, an ECMAScript implementation of the function must be done in a manner that does not cause the function's [[IsClassConstructor]] internal slot to have the value *true*.</p> | ||
| <p>The behaviour specified for each built-in function via algorithm steps or other means is the specification of the function body behaviour for both [[Call]] and [[Construct]] invocations of the function. However, [[Construct]] invocation is not supported by all built-in functions. For each built-in function, when invoked with [[Call]], the [[Call]] _thisArgument_ provides the *this* value, the [[Call]] _argumentsList_ provides the named parameters, and the NewTarget value is *undefined*. When invoked with [[Construct]], the *this* value is uninitialized, the [[Construct]] _argumentsList_ provides the named parameters, and the [[Construct]] _newTarget_ parameter provides the NewTarget value.</p> |
There was a problem hiding this comment.
I don't think this paragraph is needed. It duplicates what is already described in step 10 of [[Call]] and [[Construct]]. The only thing that's possibly useful is "[[Construct]] invocation is not supported by all built-in functions", but even then I wouldn't find that useful unless we were more explicit about what it meant to be "not supported".
| <p>The built-in function objects defined in this specification may be implemented as either ECMAScript function objects (<emu-xref href="#sec-ecmascript-function-objects"></emu-xref>) whose behaviour is provided using ECMAScript code or as function objects whose behaviour is provided in some other manner. In either case, the effect of calling such functions must conform to their specifications. An implementation may also provide additional built-in function objects that are not defined in this specification.</p> | ||
| <p>If a built-in function object is implemented as an ECMAScript function object, it must have all the internal slots described in <emu-xref href="#sec-ecmascript-function-objects"></emu-xref> ([[Prototype]], [[Extensible]], and the slots listed in <emu-xref href="#table-internal-slots-of-ecmascript-function-objects"></emu-xref>), and [[InitialName]]. The value of the [[InitialName]] internal slot is a String value that is the initial name of the function. It is used by <emu-xref href="#sec-function.prototype.tostring"></emu-xref>.</p> | ||
| <p>Built-in function objects must have the ordinary object behaviour specified in <emu-xref href="#sec-ordinary-object-internal-methods-and-internal-slots"></emu-xref>. All such function objects have [[Prototype]], [[Extensible]], [[Realm]], and [[InitialName]] internal slots, with the same meanings as above.</p> | ||
| <p>This specification defines many built-in function objects. The effect of calling such a function must conform to its specification. An implementation may also provide additional built-in function objects that are not defined in this specification.</p> |
There was a problem hiding this comment.
"This specification defines many built-in function objects." isn't doing enough work to justify itself.
Recording for posterity that the plan of @tc39/ecma262-editors to remove the notion of built-in functions that are implemented as an ECMAScript function. |
Okay, given that, I think a different approach is in order, so I'll create a new PR. This PR can probably be closed. |
|
Closing in favor of PR #3145. |
commit 1:
In the "Built-in Function Objects" section, bring together all the stuff about a built-in function being implemented as an ECMAScript function. (And downplay it by putting it at the bottom of the section.)
commit 2:
In the status quo, a built-in function can be implemented as either an ECMAScript function object (with the 10.2.1 [[Call]]) or as some other kind of function object (with the 10.3.1 [[Call]]).
Instead, this commit says that all built-in functions are 10.3.1 functions, but some can additionally be 10.2.1 functions, which is possible because 10.2.1 is a specialization of 10.3.1.
However, it appears that 10.2.1 isn't quite a specialization of 10.3.1, because 10.3.1 sets calleeContext's ScriptOrModule to
*null*, whereas 10.2.1 sets it to_F_.[[ScriptOrModule]], which I don't think is required to be*null*. Should we say it is (for a built-in ECMAScript function object)?(More generally, the spec doesn't say how a built-in ECMAScript function object would get values for most of its internal slots.)