Ecma262: Difference between Well-Known Intrinsics and Intrinsics

[dSalieri]

As mentioned earlier: https://github.com/tc39/ecma262/issues/1540

The spec doesn't really define the term "intrinsic".

But my question appears from answer @allenwb:

@erights Yes, All the objects that are created prior to execution of any code in a realm are "intrinsics".

See CreateIntrinsics() in particularly step 13 that says

Set fields of intrinsics with the values listed in Table 7 that have not already been handled above. The field names are the names listed in column one of the table. The value of each field is a new object value fully and recursively populated with property values as defined by the specification of each object in clauses 18-26. ...

The items listed in Table 7 are the Well Known Intrinsics that need to be directly referenced by the specification text. It includes among others all the objects that are specific as values of properties of the global object.

Other objects recursively specified in clauses 18-26 are also intrinsics, but are not "Well known" because there aren't any specification algorithms that need to directly refer to them.

The distinction between "intrinsic objects" and "well known intrinsic objects" probably should be clarified. Basically, the well known intrinics were always intended to be a subset of the intrinsics.

Let me structure my question so that it is easier to understand what it is about:

1. In step 13 of CreateIntrinsics (), are only Well-Known Intrinsics created?
   
   
   
   • If it true, then:
     
     
     
     
     
     1. Is step 13 a reference in the specification for the Well-Known Intrinsics? In other words, is this the reason to separate Well-Known Intrinsics from simple Intrinsics?
     
     
     
     2. Where are simple Intrinsics created?
     
     
     
   
   
   • If it false, then:
     
     
     
     
     
     1. Then what is the difference between Well-Known Intrinsics and Intrinsics? Examples?
     
     
     
   
   

[devsnek]

well known intrinsics are distinct because they're directly referenced in other specifications such as intl and html. we can move around a lot of internal stuff but they have to stay stable in relation to those specifications.

[dSalieri]

@devsnek it may sound a little rash, but I took Array.prototype.forEach as an example and looked for it in the intl and html specifications, but did not find it. I guess some other well-known intrinsics can be found in these specifications. But why can't I find my Array.prototype.forEach then?

And one more question then. Why let's say Array.prototype.forEach is well-known intrinsic, and Array.prototype.push is not. And on the basis of what is the list of well-known intrinsics made (I mean, why are some objects included and some not, reasons)?

[bathos]

@dSalieri https://heycam.github.io/webidl/#ref-for-sec-array.prototype.foreach

Intl and HTML were two specific examples of specs that include refs to ECMA262, rather than the sole examples.

[dSalieri]

@bathos what I made an assumption in the first paragraph of the second sentence. But there is also no answer to other questions that I asked.

[devsnek]

step 13 creates well known intrinsics, which inherently creates the other ones. As an example, creating Array.prototype means you have to create Array.prototype.push, even though Array.prototype.push isn't well known.

[dSalieri]

@devsnek well this is understand. But still the question that I asked earlier arises:

Why let's say Array.prototype.forEach is well-known intrinsic, and Array.prototype.push is not?

[ljharb]

Because the former is referenced directly, either in this spec or layered ones, and the latter is not. If push became directly referenced, it would have been added to the table.

[dSalieri]

@ljharb yes it’s logical you can’t argue :) Hmm. That is, the main condition for getting into a well-known intrinsic is to be used at least once in other algorithms of the ECMAScript specification. And this is the only difference between Well-Known Intrinsics and Intrinsics? Right?

[ljharb]

That's my understanding.

[dSalieri]

@ljharb interestingly, it always seemed to me that the people who are members of the tc39 committee always have some kind of general correct idea of ​​everything that goes on in the specification. Or are you unsure of your correctness? I apologize if this sounds offensive to you.

[ljharb]

I'm not the person who created the concept; I'm hesitant to speak in absolute terms, is all.

[dSalieri]

@ljharb I understood you.

[ljharb]

Seems like this is answered - can it be closed?

[dSalieri]

@ljharb Of course, this looks like an answer, and I hope that this is the correct understanding of the issue. But I would like to wait a bit to see the answers of other people who are professionals in this matter. Do you mind?

[ljharb]

Closing the issue doesn't prevent folks from commenting; I think it's better to close this.

[dSalieri]

@allenwb hey, could you please look at my questions and give your expert answer. Because I refer to your quotes, and you say in the last quote:The distinction between "intrinsic objects" and "well known intrinsic objects" probably should be clarified.

As a short summary of the problem in the form of a question and answer:

Q: What are well-known intrinsics and why? And what are regular intrinsics?
A: Well-known intrinsics are objects that are created in realm before ECMAScript code is executed. These include those objects that are either directly used by the specification itself or specifications that in some way interact with the current specification. Normal intrinsics are other objects that are created in realm before the ECMAScript code is executed, but which are not mentioned in the specification itself or in the specifications that interact with the current specification.

I would like to see your additions or amendments.

[allenwb]

Well, I would describe this more as follows. These definition could potentially be a replacement for most of the introductory paragraphs of 6.1.7.4

An _intrinsic object_ is an object that meets all of these requirements:

1. its existence is defined by this specification or related specifications
2. it is observable to ECMAScript code
3. its initial state is fully defined by its specification and is not dependent upon prior execution of any ECMAScript code.

Each Realm is associated with a complete set of intrinsic objects that is (unless otherwise specified) disjoint from the intrinsic set of any other realm.

A _well-known intrinsic_ is an intrinsic that is explicitly referenced by an algorithm or requirement of this specification or of a related specification. Each such intrinsic is assigned a name of the form %name% which is used for such textual references. Each Realm maintains an association between the well-known intrinsic names and that Realm's corresponding intrinsic objects. A textual reference such as %name% means the intrinsic object, associated with the current Realm, corresponding to the name.

Intrinsics that are not well-known intrinsics are objects that are accessible (possibly indirectly) as the initial values of the properties and slots of the well-known intrinsics.

[allenwb]

I should probably add that the concept of well-known intrinsics was added in ES6 because prior editions used informal language such as the "the built-in Array object" or "the original value of Object.prototype" which was subject to (mis) interpretation and did not account for the existence of multiple Realms.

[dSalieri]

@allenwb is a great addition, I think it should be included in the new edition of the specification. Thank you for responding and leaving your great answer.

But it seems to me that you need to clarify which specifications are related to ECMAScript. I assume that not every specification is such (related).