"ECMAScript function object"

[jmdyck]

Clause 9.2 says that an ECMAScript function object is both a function object and an ordinary object. But is the converse true? I.e., if an object is both a function object and an ordinary object, is it necessarily an ECMAScript function object?

The spec doesn't explicitly say so, but there doesn't appear to be room for anything else. As a function object, it must have a [[Call]] internal method, and as an ordinary object, its [[Call]] must have the "default semantics". But the only default semantics for [[Call]] is clause 9.2.1, which asserts that it's the [[Call]] of an ECMAScript function object.

[allenwb]

Strictly speaking an ordinary object is one that implements the internal methods as specified in 9.1 and an ordinary function object is an ordinary object that also implements the [[Call]] and [[Construct]] internal methods as specified in 9.2.

You could say that where "ordinary object" is defined in 6.7.1.

An otherwise ordinary object that implements [[Call]], but not in conformance to 9.2 is an exotic function object.

[jmdyck]

Hm, your reply doesn't mention "ECMAScript function object", which is the focus of the question. But it sounds to me like you'd agree that an object that is both a function object and an ordinary object is necessarily an ECMAScript function object. Is that correct?

[allenwb]

Yes, I was talking specifically about ECMAScript function objects as defined in 9.2

[jmdyck]

So, given that equivalence, I was going to suggest replacing the term "ECMAScript function object" with "ordinary function object" (since, to me at least, the latter's meaning seems clearer), but then I noticed that "ordinary function object" was used for about 8 drafts of ES6, but then (in rev 20), it was changed to "ECMAScript function object". Do you (or does anyone) recall why that was? I can't find any discussion of it before or after.

[allenwb]

Yes, because the the most important characteristic of ECMAScript function objects is that they implement [[Call]] by executing an ECMAScript code body. The name is selected to emphasize that characteristic. In other words, they are the function objects that implement the semantics for functions defined using the ECMAScript language.

[allenwb]

Also, we wanted to emphasize that a BuitinFunctionObject could be either an ECMAScript function object or an implementation provided exotic function object.

[jmdyck]

the most important characteristic of ECMAScript function objects is that they implement [[Call]] by executing an ECMAScript code body. The name is selected to emphasize that characteristic. In other words, they are the function objects that implement the semantics for functions defined using the ECMAScript language.

While I agree that's an important characteristic, it presumably isn't a defining characteristic, because a function exotic object could also implement [[Call]] by executing ECMAScript code, just not exactly the way that 9.2.1 [[Call]] does.

To me, the "ECMAScript" prefix simply suggests "as defined in the ECMAScript specification", the same way one might say "ECMAScript primitive value" or "ECMAScript execution context". I can understand that the spec intends a different meaning, but outside the spec, I think both meanings occur, and it's sometimes hard to tell which is meant.

Also, we wanted to emphasize that a BuitinFunctionObject could be either an ECMAScript function object or an implementation provided exotic function object.

A fine thing to emphasize, but I don't agree that this choice of term for the first alternative helps the emphasis. Given the dichotomy of ordinary vs exotic, it seems to me that saying a built-in can be ordinary or exotic would be no less emphatic.

[allenwb]

While I agree that's an important characteristic, it presumably isn't a defining characteristic, because a function exotic object could also implement [[Call]] by executing ECMAScript code, just not exactly the way that 9.2.1 [[Call]] does.

It is the defining characteristic, WRT this specification as no such exotic function objects exist within the specification. Providing the specific semantics of evaluating functions defined using ECMAScript code is arguably on of the major purposes of ECMA-262. The specification text in 9.2 is the starting point for that semantics.

If you think the name is not sufficiently descriptive, propose a more descriptive name. We considered using "ECMAScript code function" but the addition of "code" didn't seem to add enough clarity. In either case, these terms i probably needs to be understood by looking at an explicit definition.

Subclause 4.3 ("Terms and Definitions") has been largely ignored (except for 4.3.6 and 4.3.70 since the completion of ES5. We probably should consider adding some new definitions to 4.3 and "ECMAScript function object" should be one of them.

[jmdyck]

If you think the name is not sufficiently descriptive, propose a more descriptive name.

Now I'm thinking there's actually 2 distinct concepts, each needing a name:

• An object that is both an ordinary object and a function object.

• A function object whose [[Call]] semantics are supplied by an ECMAScript code body.

For the first, I think "ordinary function [object]" is the obvious choice.

The second is harder though. Here are some possibilities:

• "ECMAScript function object" is a contender, but has the problem I mentioned above.
• "ECMAScript code function" seems clearer, but not enough, you say.
• "code-based function"
• "in-language function"
• "native function"
• "source text function" (by analogy with "source text module record")

I don't much like any of these, for various reasons. Instead, I'm focusing on the word "body", which has the advantage of echoing the |FunctionBody|, |GeneratorBody| etc nonterminals. Specifically, I like the term embodied function.

Here is some sample (non-spec) text using these terms to answer (something like) the original question of this PR:

Every ordinary function is an embodied function, because that's
the only kind of function that 9.2.1 [[Call]] knows how to execute.

Moreover, the converse is mostly true, insofar as every embodied function
that the spec deals with is an ordinary function. (9.2.1 is the only mechanism
that the spec defines for executing an embodied function.)

However, implementations are permitted to define other mechanisms
to execute embodied functions, which would thus be exotic functions
(function exotic objects).

In either case, these terms i probably needs to be understood by looking at an explicit definition.

Certainly! But:

• Once you've understood the definition, does the term readily suggest that meaning when you read it elsewhere in the spec?

• If you read the term outside the spec, can you be fairly confident that the writer means it in the sense defined by the spec?