search

tc39 / ecma262

Status, process, and documents for ECMA-262
https://tc39.es/ecma262/
Other
15.03k stars 1.28k forks source link

Editorial: what is a built-in object? #2608

Open bergus opened 2 years ago

bergus commented 2 years ago

While writing this StackOverflow answer, I was not quite certain about the definition of built-in objects:

object specified and supplied by an ECMAScript implementation

NOTE: Standard built-in objects are defined in this specification. An ECMAScript implementation may specify and supply additional kinds of built-in objects. A built-in constructor is a built-in object that is also a constructor.

I've tried to dichotomise them with "user-defined objects", where the built-ins are created by the implementation at startup, providing the environment that user code can interact with, and the user-defined ones are constructed by user code at runtime.

In #1540 I also found the related terms primordial and intrinsic as defined at https://github.com/tc39/how-we-work/blob/master/terminology.md, which basically mean "standard builtins" (built-in objects required by the ECMAScript standard) according to my understanding.

However, what confused me is the section 10.4 "Built-in Exotic Object Internal Methods and Slots":

This specification defines several kinds of built-in exotic objects.

Either my understanding of built-in objects as statically created intrinsics is wrong, or this really should say "standard objects" not "built-in objects". Bound functions, Array instances, String instances, arguments objects and typed array instances are all constructed at runtime, by user code. I would not classify them as built-in objects? I think they should be named "standard exotic objects". The only exception in this section would be Immutable Prototype Exotic Objects, where %Object.prototype% is indeed a builtin (but still a standard exotic built-in object), and Module Namespace Exotic Objects, which cannot be constructed by user code. (I'm also missing proxy exotic objects under 10.4, no idea why they got a separate section 10.5)

The title of the section "Built-in Exotic Object Internal Methods and Slots" has an ambiguity where "built-in" may refer to either the "exotic object" or to the "internal methods and slots". The latter are indeed built-in, just like there are also "built-in types" or "built-in operators" in the spec, but I'd change it to "Standard …" either way (or omit it altogether). The adjective "Standard" has also been brought up here when discussing 10.3 "Built-in Function Objects".

Or is my understanding completely wrong, and the term "built-in objects" actually does mean to include arrays, bound functions etc, as they are "specified and supplied by an ECMAScript implementation"? But what does count as a non-built-in object then? Is any object supplied by a call to OrdinaryObjectCreate also a built-in object?

bergus commented 2 years ago

More things that are at odds with my understanding:

@allenwb wrote in https://github.com/tc39/ecma262/issues/1273#issuecomment-407967203

a BuitinFunctionObject could be either an ECMAScript function object or an implementation provided exotic function object.

and that section 10.3.3 CreateBuiltinFunction is called also with abstract closures for promise callbacks at runtime, and for class definitions without a constructor.

ljharb commented 2 years ago

Abstract closures didn't exist in 2018, when that comment was written; if that helps.

bergus commented 2 years ago

I didn't mean that those things contradict each other, but that both don't fit in my understanding of the term "built-in". I would have expected

jmdyck commented 2 years ago

... where the built-ins are created by the implementation at startup, providing the environment that user code can interact with, and the user-defined ones are constructed by user code at runtime.

That will run into some problems: search the spec for occurrences of "anonymous built-in function" (other than %ThrowTypeError%) and you'll find functions that are not created at startup, but rather in response to user code.

In #1540 I also found the related terms primordial and intrinsic as defined at https://github.com/tc39/how-we-work/blob/master/terminology.md, which basically mean "standard builtins" (built-in objects required by the ECMAScript standard) according to my understanding.

If an implementation added non-standard objects to the initial environment, I think I'd call those intrinsics too.

However, what confused me is the section 10.4 "Built-in Exotic Object Internal Methods and Slots":

This specification defines several kinds of built-in exotic objects.

Either my understanding of built-in objects as statically created intrinsics is wrong, or this really should say "standard objects" not "built-in objects".

I'm inclined to agree. The spec definitely does define built-in exotic objects (e.g. %Array.prototype%), but they're not really the topic of 10.4.

Bound functions, Array instances, String instances, arguments objects and typed array instances are all constructed at runtime, by user code. I would not classify them as built-in objects?

Right. They're not "supplied" by the implementation, except in the unhelpful sense that everything is supplied by the implementation.

The title of the section "Built-in Exotic Object Internal Methods and Slots" has an ambiguity where "built-in" may refer to either the "exotic object" or to the "internal methods and slots".

Given that the first sentence refers to "built-in exotic objects", my guess is that the title's intended meaning was "Internal Methods and Slots of Built-in Exotic Objects".

The latter are indeed built-in, just like there are also "built-in types" or "built-in operators" in the spec, but I'd change it to "Standard …" either way (or omit it altogether).

I wouldn't omit it, because the section isn't talking about all possible exotics, just the standard ones. So I'd vote for "Internal Methods and Slots of Standard Exotic Objects".

jmdyck commented 2 years ago

I didn't mean that those things contradict each other, but that both don't fit in my understanding of the term "built-in". I would have expected

  • "a function object can be either an ECMAScript function object (ordinary function defined by user code) or an exotic function object (implemented in native code, either standard or implementation-defined)"

That's correct. (Though I think "implemented in native code" is too specific.)

  • "a builtin function object can be either a standard exotic function object (specified by ECMAScript) or an implementation-defined function object".

Hm, no. As I understand it, there are 3 mutually orthogonal dichotomies for objects (not just functions):

All 8 combinations are allowed, though a given implementation need not exhibit all of them.

(Not sure whether a host can build-in an ordinary function object?)

Yes, a built-in function can be ordinary.

  • CreateBuiltinFunction should be called CreateNativeFunction, and "native function" should be defined as "a function implemented (usually in native code) by the implementation", opposed to ECMAScript function objects that are defined by user code.

No, the spec explicitly says that built-in functions can be ECMAScript function objects.

bergus commented 2 years ago

Thanks for the clarifications @jmdyck!

built-ins are created by the implementation at startup, providing the environment that user code can interact with

That will run into some problems: search the spec for occurrences of "anonymous built-in function" and you'll find functions that are not created at startup

Ah, so "built-in" really is supposed to mean "built into the implementation" as opposed to "defined by user code", regardless whether it is an intrinsic created at startup or created dynamically.

They're not "supplied" by the implementation, except in the unhelpful sense that everything is supplied by the implementation.

I think this best describes my issue. Where to draw the line? Would it make sense to distinguish between "built-in objects" (= intrinsics) and "built-in functions" (= functions whose behaviour is built into the implementation)? Also happy to call these "native functions", unless that introduces additional ambiguity.

My guess is that the title's intended meaning was "Internal Methods and Slots of Built-in Exotic Objects".

Yes, that was my guess as well, and it felt wrong.

I wouldn't omit it, because the section isn't talking about all possible exotics, just the standard ones. So I'd vote for "Internal Methods and Slots of Standard Exotic Objects".

Sure, anything that doesn't call them "built-in" is fine for me :-) I guess I just wouldn't call out "standard" since that's the implicit default for everything described in the specification, only non-standard objects need to be marked as "implementation-defined".

the spec explicitly says that built-in functions can be [ordinary] ECMAScript function objects

Oh, I didn't know that. Is it intentional that these can have an arbitrary [[SourceText]], which is not necessarily a NativeFunction? I kinda would have expected Function.prototype.toString to always return [ native code ] for native, uh, built-in functions. (And also would have expected it to throw an exception on non-callable objects, regardless whether they have a [[SourceText]] or not).

"a builtin function object can be either a standard exotic function object (specified by ECMAScript) or an implementation-defined function object".

Hm, no. As I understand it, there are 3 mutually orthogonal dichotomies for objects

Ah, right, I didn't consider built-in ordinary functions. Not having read the 10.3 "Built-in Function Objects" prose properly, I thought they would always need to have exotic [[Call]] / [[Construct]] as defined in 10.3 .

All 8 combinations are allowed, though a given implementation need not exhibit all of them.

Right. I would however distinguish

where user-defined functions are necessarily non-intrinsic. Also I had some trouble imagining implementation-defined (i.e. non-standard) user-defined (i.e. non-built-in) functions, but I suppose a custom function definition language like WebAssembly would qualify. Those would necessarily need to be exotic though?

Also, isn't an ordinary object also necessarily a standard object? The only thing I could think of would be an object whose existence is non-standard, i.e. it's an intrinsic that but not part of the standard intrinsics…

jmdyck commented 2 years ago

Ah, so "built-in" really is supposed to mean "built into the implementation" as opposed to "defined by user code", regardless whether it is an intrinsic created at startup or created dynamically.

That might be a good way to think of it, although "built into the implementation" isn't that great from a definitional perspective. (Sometimes I think that "built-in function" doesn't really have an intensional definition, it's just whatever the spec says is created by CreateBuiltinFunction.)

Would it make sense to distinguish between "built-in objects" (= intrinsics) and "built-in functions" (= functions whose behaviour is built into the implementation)?

I'm not sure what you're getting at there. In my understanding:

Is it intentional that these can have an arbitrary [[SourceText]], which is not necessarily a NativeFunction?

Hm. An ordinary [ECMAScript] function is required to have (i.e., behave as if it had) a [[SourceText]] slot. But if a built-in function is implemented as an ordinary function, the spec is kind of vague about how its [[SourceText]] gets set. (The same is true of almost every slot in Table 34: Internal Slots of ECMAScript Function Objects.) I imagine it's intentional that there's no requirement that the [[SourceText]] of an ordinary built-in function conform to the NativeFunction production.

I kinda would have expected Function.prototype.toString to always return [ native code ] for native, uh, built-in functions.

That does not appear to be guaranteed. An ordinary built-in function will have a [[SourceText]] slot, and for an exotic built-in function, the impl can add a [[SourceText]] slot; in either case if it's Unicode text and HostHasSourceTextAvailable returns true, Function.p.toString won't get to step 3.

(And also would have expected it to throw an exception on non-callable objects, regardless whether they have a [[SourceText]] or not).

(Apparently, Function.p.toString wants to defy your expectations.)

I would however distinguish

  • intrinsic (supplied by the engine at startup) vs non-intrinsic (created due to user code execution)

I agree that that's a dichotomy, though it isn't orthogonal to the built-in/non-built-in axis. (There's no such thing as an intrinsic non-built-in. I think.)

  • for functions: built-in/native (with hardwired behaviour implemented in the engine) vs non-built-in/non-native/user-defined (with as behaviour defined by user code)

So if an implementation implements (say) String.p.repeat as an ordinary function, that would fall in the first group?

Also I had some trouble imagining implementation-defined (i.e. non-standard) user-defined (i.e. non-built-in) functions,

Actually, I've lost track of what I had in mind for "standard" yesterday.

but I suppose a custom function definition language like WebAssembly would qualify. Those would necessarily need to be exotic though?

Yup.

Also, isn't an ordinary object also necessarily a standard object?

The definition for standard object is "object whose semantics are defined by this specification". If that means an object whose internal methods have spec-supplied algorithms, then yes every ordinary object is a standard object.

But by that interpretation, every built-in function (regardless of how it's implemented, and regardless of whether it's a function defined in the spec) would be a standard object. And if you can't say "a non-standard built-in function", I'm not sure that's a good meaning for "standard".

The only thing I could think of would be an object whose existence is non-standard, i.e. it's an intrinsic that but not part of the standard intrinsics…

If "standard object" meant something like "object whose existence is guaranteed by the spec", then yeah it would make sense to talk about [non-]standard built-ins and [non-]standard intrinsics.

bergus commented 2 years ago

Apparently, Function.protoype.toString wants to defy your expectations.

Yeah, so it seems :-) Maybe I'll open another issue to discuss that in particular.

intrinsic (supplied by the engine at startup) vs non-intrinsic (created due to user code execution)

I agree that that's a dichotomy, though it isn't orthogonal to the built-in/non-built-in axis. (There's no such thing as an intrinsic non-built-in. I think.)

Yes, I meant that as a replacement (with different name and meaning) for the built-in/non-built-in axis, which seemed unhelpful with its current definition (as "objects supplied by the implementation").

for functions: built-in/native (with hardwired behaviour implemented in the engine) vs non-built-in/non-native/user-defined (with as behaviour defined by user code)

So if an implementation implements (say) String.prototype.repeat as an ordinary function, that would fall in the first group?

Yes. It only matters that it's implemented by the ECMAScript host implementation, not whether it's an ordinary native function or an exotic native function.

The definition for standard object is "object whose semantics are defined by this specification". If that means an object whose internal methods have spec-supplied algorithms, then yes every ordinary object is a standard object.

But by that interpretation, every built-in function (regardless of how it's implemented, and regardless of whether it's a function defined in the spec) would be a standard object. And if you can't say "a non-standard built-in function", I'm not sure that's a good meaning for "standard".

How so? A built-in function could be a function object with an algorithm not defined by the ECMAScript standard, implemented either as an exotic function (with custom [[Call]]) or as an ordinary function with custom source code.

jmdyck commented 2 years ago

intrinsic (supplied by the engine at startup) vs non-intrinsic (created due to user code execution)

[...] I meant that as a replacement (with different name and meaning) for the built-in/non-built-in axis,

Yup, that seems valid. (intrinsic/non-intrinsic is orthogonal to ordinary/exotic).

for functions: built-in/native (with hardwired behaviour implemented in the engine) vs non-built-in/non-native/user-defined (with as behaviour defined by user code)

So if an implementation implements (say) String.prototype.repeat as an ordinary function, that would fall in the first group?

Yes. It only matters that it's implemented by the ECMAScript host implementation, not whether it's an ordinary native function or an exotic native function.

So isn't that the same dichotomy as built-in vs non-built-in?

The definition for standard object is "object whose semantics are defined by this specification". If that means an object whose internal methods have spec-supplied algorithms, then yes every ordinary object is a standard object. But by that interpretation, every built-in function (regardless of how it's implemented, and regardless of whether it's a function defined in the spec) would be a standard object. And if you can't say "a non-standard built-in function", I'm not sure that's a good meaning for "standard".

How so? A built-in function could be a function object with an algorithm not defined by the ECMAScript standard, implemented either as an exotic function

Yes.

(with custom [[Call]])

No. In general, an exotic function can have a custom [[Call]] method, but a built-in function implemented as an exotic cannot be just any exotic function. See 10.3 Built-in Function Objects, last paragraph: "If a built-in function object is not implemented as an ECMAScript function [i.e., if it's implemented as an exotic function] it must provide [[Call]] and [[Construct]] internal methods that conform to the following definitions".

I.e., a built-in function's [[Call]] method has exactly two possibilities: the ordinary [[Call]] of 10.2.1 or the exotic [[Call]] of 10.3.1. Either way, all of a built-in function's internal methods are spec-supplied algorithms.

or as an ordinary function with custom source code.

Yes.

bergus commented 2 years ago

It only matters that it's implemented by the ECMAScript host implementation

So isn't that the same dichotomy as built-in vs non-built-in?

Maybe? That's why I called it "built-in function" or "native function". But the difference to the current definition of "built-in" in the spec is that my term only applies to function objects, and is only concerned with what [[Call]] does. As established, I don't think it makes sense to call any object built-in just because it has some of its characteristics implemented natively in the engine, or it was created by the engine. The ordinary/exotic and intrinsic/non-intrinsic dichotomies handle those aspects much better with a clear definition. Proxy instances, arrays, iterator result objects, property descriptor objects, collections, typed arrays, promises - I wouldn't call them "built-in" any more than objects created from object literals. Bringing up the WebAssembly function example again, even if that is an exotic object and may have custom slots or non-default internal methods (necessarily defined by the implementation), it is ultimately a user-defined function to me, not a built-in function.

A built-in function could be a function object with an algorithm not defined by the ECMAScript standard, implemented either as an exotic function (with custom [[Call]])

No. In general, an exotic function can have a custom [[Call]] method, but a built-in function implemented as an exotic cannot be just any exotic function. See 10.3 Built-in Function Objects, last paragraph: "If a built-in function object is not implemented as an ECMAScript function [i.e., if it's implemented as an exotic function] it must provide [[Call]] and [[Construct]] internal methods that conform to the following definitions".

I.e., a built-in function's [[Call]] method has exactly two possibilities: the ordinary [[Call]] of 10.2.1 or the exotic [[Call]] of 10.3.1. Either way, all of a built-in function's internal methods are spec-supplied algorithms.

I understand that "conforming to these definitions" in 10.3 does specify invariants, or at best templates, not concrete algorithms. Given that "An implementation may also provide additional built-in function objects that are not defined in this specification", not all built-in functions have spec-supplied algorithms. Things like setTimeout are non-standard, but built-in, in my book.

Also I think that the sentence "If a built-in function object is not implemented … it must provide …" really should only apply to standard functions. The whole section 10.3 speaks about "The built-in function objects defined in this specification", which "may be implemented as either ECMAScript function objects (10.2) whose behaviour is provided using ECMAScript code or as implementation provided function exotic objects whose behaviour is provided in some other manner."

I do believe that implementations are allowed to provide exotic function objects with [[Call]] and/or [[Construct]] methods that do not conform to 10.3.1/10.3.2. Proxy function objects and bound function objects are examples of this, and I see no reason why an implementation couldn't extend this to other exotic function kinds. Some of which are implemented by user code, others I would classify as built-in.

jmdyck commented 2 years ago

Proxy instances, arrays, iterator result objects, property descriptor objects, collections, typed arrays, promises - I wouldn't call them "built-in" any more than objects created from object literals.

Okay. Are you saying that the current definition would call them built-in?

I understand that "conforming to these definitions" in 10.3 does specify invariants, or at best templates, not concrete algorithms.

But is that particular to 10.3? Are there spec algorithms that you would say are concrete?

Given that "An implementation may also provide additional built-in function objects that are not defined in this specification", not all built-in functions have spec-supplied algorithms.

I think we need some more precision here. Note that there are two levels of algorithm involved. One is what a user would read to find out what the function does (call it 'behavior', say), and another is what a function's [[Call]] is set to. You can have a function whose [[Call]] is spec-defined but whose 'behavior' is not spec-defined. (So I'd say that a built-in function has a spec-defined [[Call]], but might or might not have a spec-defined 'behavior'.)

(Note that there's a similar problem with "semantics defined by this specification" in the definition of 'standard object'. If a function's [[Call]]-level semantics are defined the spec, but its 'behavior'-level semantics aren't, the definition is unclear as to whether the function is 'standard' or not.)

Things like setTimeout are non-standard, but built-in, in my book.

And that seems sensible to me. I was just saying it might not be compatible with an interpretation in which every ordinary object is a standard object.

Also I think that the sentence "If a built-in function object is not implemented … it must provide …" really should only apply to standard functions. The whole section 10.3 speaks about "The built-in function objects defined in this specification", which "may be implemented as either ECMAScript function objects (10.2) whose behaviour is provided using ECMAScript code or as implementation provided function exotic objects whose behaviour is provided in some other manner."

Yes, the first sentence of 10.3 does have the qualification "defined in this specification", but then the last sentence of the paragraph talks about "additional built-in function objects that are not defined in this specification". So, having introduced built-in functions both defined in the spec and not, it would be reasonable to think that subsequent references to "built-in functions" without qualification include both.

I do believe that implementations are allowed to provide exotic function objects with [[Call]] and/or [[Construct]] methods that do not conform to 10.3.1/10.3.2.

Sure they are. I said as much in my previous comment.

Proxy function objects and bound function objects are examples of this, and I see no reason why an implementation couldn't extend this to other exotic function kinds.

Yup.

Some of which are implemented by user code, others I would classify as built-in.

Are you saying that the current definition of "built-in" allows you to classify them that way, or that you would like it to have a definition that allows you to classify them that way?

bergus commented 2 years ago

Are you saying that the current definition would call them built-in?

Yes. Or: it could at least be misunderstood so. The current spec does (wrongly imo) call proxies and arrays "built-in objects", and I guess the definition "specified and supplied by the implementation" could reasonably be construed to also mean iterator result objects and property descriptor objects. But this stretch is what makes the current definition rather useless.

I understand that "conforming to these definitions" in 10.3 does specify invariants, or at best templates, not concrete algorithms.

But is that particular to 10.3?

Yes, that was particular to 10.3.1 and 10.3.2. They have gaping holes that say "fill in the actual algorithm here" :-) But you're right:

I think we need some more precision here. Note that there are two levels of algorithm involved. One is what a user would read to find out what the function does (call it 'behavior', say), and another is what a function's [[Call]] is set to. You can have a function whose [[Call]] is spec-defined but whose 'behavior' is not spec-defined. (So I'd say that a built-in function has a spec-defined [[Call]], but might or might not have a spec-defined 'behavior'.)

I knew you'd call me out on that - I noticed but I can't come up with a good definition for this "behaviour".

Of course even ordinary, user-defined ECMAScript function objects do have a [[Call]] method with an algorithm that is spelled out in the specification (namely, to interpret the source code of the function).

I was just saying [setTimeout being non-standard] might not be compatible with an interpretation in which every ordinary object is a standard object.

Oh, good call!

Having introduced built-in functions both defined in the spec and not, it would be reasonable to think that subsequent references to "built-in functions" without qualification include both.

Hm, yeah.

I do believe that implementations are allowed to provide exotic function objects with [[Call]] and/or [[Construct]] methods that do not conform to 10.3.1/10.3.2.

Sure they are.

So would you just not count these as built-in functions?

Are you saying that the current definition of "built-in" allows you to classify them that way, or that you would like it to have a definition that allows you to classify them that way?

I would like to have a term with a definition that would classify them that way. I thought "built-in" would be that term, but would also be happy to call them "native" instead or something like that. It's just that if "built-in" means something else, I don't understand its definition - bringing me back to the titular question "What is a built-in object?". If what you say is true, and it's not meant to have an intensional definition, I would suggest to remove it from 4.4 Terms and Definitions altogether.

jmdyck commented 2 years ago

You can have a function whose [[Call]] is spec-defined but whose 'behavior' is not spec-defined. (So I'd say that a built-in function has a spec-defined [[Call]], but might or might not have a spec-defined 'behavior'.)

I knew you'd call me out on that - I noticed but I can't come up with a good definition for this "behaviour".

Yeah, I'm doubtful I'd be able to either.

Of course even ordinary, user-defined ECMAScript function objects do have a [[Call]] method with an algorithm that is spelled out in the specification (namely, to interpret the source code of the function).

Right, so its [[Call]] is definitely spec-defined, but 'behavior' is typically not.

I do believe that implementations are allowed to provide exotic function objects with [[Call]] and/or [[Construct]] methods that do not conform to 10.3.1/10.3.2.

Sure they are.

So would you just not count these as built-in functions?

(Ah, sorry, when you said "provide", you meant as built-ins (or, to avoid the problematic term, as intrinsics). I had something else in my head when I said "Sure they are".)

As I understand it, if an implementation provides an exotic intrinsic function that doesn't conform to 10.3.1/2, then that's a non-conforming implementation. (So whether I'd count that function as "built-in" is kind of beside the point. I guess if it's a non-conforming implementation, they can call it whatever they like.)

More practically, I wonder if conforming to 10.3.1/2 is much of a burden. It seems like sort of the minimum housekeeping for the function call to make sense.

It's just that if "built-in" means something else, I don't understand its definition - bringing me back to the titular question "What is a built-in object?". If what you say is true, and it's not meant to have an intensional definition,

Note that I'm claiming that, that's just how it seems to me sometimes. (That clarification is more for the benefit of someone dipping into the conversation at this point.)

Some history: The term "built-in object" has been in the spec since ES1. Up to and including ES5.1, the definition included the phrase "that is present at the start of the execution of an ECMAScript program". ES6 dropped that phrase from the definition and introduced "anonymous built-in functions" that are created (if at all) in response to the execution of user code.

I would suggest to remove it from 4.4 Terms and Definitions altogether.

(See also #1278.)

bergus commented 2 years ago

As I understand it, if an implementation provides an exotic intrinsic function that doesn't conform to 10.3.1/2, then that's a non-conforming implementation. More practically, I wonder if conforming to 10.3.1/2 is much of a burden. It seems like sort of the minimum housekeeping for the function call to make sense.

I was thinking of something like a Function.prototype.partiallyApply(...args) method that works just like bind except binding only arguments but not the this value, and would return an exotic function object with a custom [[Call]] algorithm. Similar to a bound function, it would not push an extra execution context on the call stack, it would just forward to the [[Call]] method of the target function. I think an implementation creating such exotic functions should count as conforming.

Some history: The term "built-in object" has been in the spec since ES1. Up to and including ES5.1, the definition included the phrase "that is present at the start of the execution of an ECMAScript program". ES6 dropped that phrase from the definition and introduced "anonymous built-in functions" that are created (if at all) in response to the execution of user code.

Oh, that's an extra source of confusion. So "built-in" basically did mean "intrinsic" until ES5!

Now, how do we resolve this situation? Would you accept a pull request where I try to straighten this out? Do we need to involve anyone else from the committee? Or is it deemed unnecessary to change the specification for this?

jmdyck commented 2 years ago

I was thinking of something like a Function.prototype.partiallyApply(...args) method that works just like bind except binding only arguments but not the this value, and would return an exotic function object with a custom [[Call]] algorithm. Similar to a bound function, it would not push an extra execution context on the call stack, it would just forward to the [[Call]] method of the target function. I think an implementation creating such exotic functions should count as conforming.

Yeah, I don't think that's a problem. The within-standard analogy is Function.prototype.bind, which is a built-in function (and so must have a [[Call]] that conforms to 10.2.1/10.3.1), and yet it creates functions whose [[Call]] conforms to 10.4.1.1 (and so can't be considered "built-in"). (Likewise, the Proxy constructor is a built-in function that can create non-built-in functions.) So, on the non-standard side, I don't think there's anything non-conformant about supplying a built-in F.p.partiallyApply that conforms to 10.{2,3}.1 but creates functions that don't.

Oh, that's an extra source of confusion. So "built-in" basically did mean "intrinsic" until ES5!

Yeah, the distinction we now have between "built-in" and "intrinsic" wasn't really needed until ES6, I think.

Now, how do we resolve this situation? Would you accept a pull request where I try to straighten this out?

It's not up to me to accept or reject, though I'd probably have comments. If you're only straightening out terminology, then you'd theoretically only need approval from the editors.

bergus commented 2 years ago

Yeah, I don't think that's a problem. […] it creates functions whose [[Call]] conforms to 10.4.1.1 (and so can't be considered "built-in")

Ok, so yes you don't consider these to be built-in. They would be "native" (with implementation-defined behavior) functions though?

It's not up to me to accept or reject, though I'd probably have comments. If you're only straightening out terminology, then you'd theoretically only need approval from the editors.

Good! Then I'll wait for comments from the editors whether they consider this to be a problem worth fixing before drafting a PR.

jmdyck commented 2 years ago

Yeah, I don't think that's a problem. […] it creates functions whose [[Call]] conforms to 10.4.1.1 (and so can't be considered "built-in")

Ok, so yes you don't consider these to be built-in.

(On second thought, it's tricky. One could try to argue that (e.g.) a bound function's [[Call]], while conforming to 10.4.1.1, also conforms to 10.2.1 or 10.3.1, and so could qualify as a built-in function. I think that argument is incorrect, but I'm not positive.)

They would be "native" (with implementation-defined behavior) functions though?

Presumably you would define "native" so that they are.

Note that the spec has used the term "native" in the past, with a different meaning. From ES1 to ES5.1, it went something like:

(Not that that precludes a new definition of "native", it's just maybe worth mentioning, so that it's not a source of confusion.)

Then I'll wait for comments from the editors whether they consider this to be a problem worth fixing before drafting a PR.

You might want to re-state your current understanding of the problem(s), so that people can get that without reading the whole preceding discussion.

bergus commented 2 years ago

Note that the spec has used the term "native" in the past, with a different meaning. From ES1 to ES5.1, it went something like […]

Ah right, that's the dichotomy I remember. I had wanted to check in which revision exactly these definitions changed, didn't get to it until now - it was ES6 apparently. So yeah, maybe re-defining "native" is not the best idea.

You might want to re-state your current understanding of the problem(s), so that people can get that without reading the whole preceding discussion.

I suggest the following editorial changes:

I suggest the following changes with possible normative impact: