Editorial: Consistify prose for intrinsic functions #2592

jmdyck · 2021-11-29T02:09:26Z

Issue #2576 didn't get very far, so I created this PR to spur discussion/decisions.

The first 4 commits perform small spot fixes.

The next 2 commits normalize the use of "method" vs "function". I started with the rule that a method is a function that is the value of a property of a prototype object, because it's easy for me to detect automatically, but then added special cases for [Typed]Array.{from,of}. I made each 'direction' (method-to-function vs function-to-method) a separate commit, because I think it's easier to review the changes that way, but they could probably be squashed later.

The remaining 12 commits perform various widespread normalizations on intrinsic function prose. I've left them as distinct commits in case you want me to back out particular changes. It might also help with review. Anyhow, they could probably be squashed too.

Resolves #2304 (at least to some extent: it depends on how broadly you interpret #2304)

jmdyck · 2021-11-29T02:15:36Z

There's another inconsistency that might be within the scope of this PR, but I didn't do anything about it because I'm not sure how to resolve it. When a function definition includes a prose summary, it's sometimes a , and sometimes an <emu-note>. The ones that are Notes are mainly in String.prototype.* and Array.prototype.*.

For example,

String.p.charCodeAt has a summary-in-a-Note,
String.p.matchAll has a summary-in-a-p.
Array.prototype.copyWithin has a summary-in-a-Note (actually 2 Notes),
Array.prototype.concat has a summary-in-a-p.

It looks like the summaries-as-Notes arose in ES6. The old ecmascript.org wiki says:

We generally within the specification try to minimize tutorial material (eg examples) and redundancy between normative prose descriptions and normative algorithms. Redundant descriptions has historically resulted in internal inconsistencies. We have also seen cases where implementors follow incomplete prose descriptions without referring to the more complete algorithm. For these reasons, much of the redundant prose from previous editions is being converted into non-normative notes.

My guess is that this was written by @allenwb, and refers to the summaries-as-notes we see in String.p.* and Array.p.*.

Here are some possible actions:

Leave it as is. (Maybe resolve it later.)
Change all the <emu-note> summaries to  summaries.
Change all the  summaries to <emu-note> summaries.
Change all summaries to something different. (e.g.,  or <div class="summary">. It could get some distinctive styling and we could explain its status in the frontmatter.)
Delete all summaries.

There's a related oddity that sometimes a summary-as-Note appears after the <emu-alg>.
E.g.

We could easily move these up, but it's maybe not worth it until we have a solution to the Note-vs-p problem.

ljharb · 2021-11-29T02:24:16Z

What about the Promise statics?

ljharb · 2021-11-29T02:27:50Z

spec.html

@@ -13480,13 +13480,15 @@ <h1>

      <emu-clause id="sec-%throwtypeerror%">
        <h1>%ThrowTypeError% ( )</h1>
-        <p>The <dfn>%ThrowTypeError%</dfn> intrinsic is an anonymous built-in function object that is defined once for each realm. When %ThrowTypeError% is called it performs the following steps:</p>
+        <p>This function is the <dfn>%ThrowTypeError%</dfn> intrinsic object.</p>


“intrinsic object” seems redundant here; the % syntax already conveys that.

So would you prefer
This function is <dfn>%ThrowTypeError%</dfn>.
? And likewise for the other function properties of the global object?

The words "intrinsic object" are certainly redundant, but they might be useful. Imagine someone is browsing the spec, and they don't know about intrinsic objects, but they come across one of these percent-thingies, so they click on it and land at a clause that says "This function is %foo%." Well, that's something, but it doesn't explain what a percent-thingy is. However, saying "This function is the %foo% intrinsic object" would give them a phrase that they could then look up. (It would be better if "intrinsic object" were an auto-linked phrase.)

Yes, that’d be what i expect.

% syntax should ideally link to the section describing it, yes.

% syntax should ideally link to the section describing it, yes.

Are you saying that uses of the % syntax (e.g. %Foo%) should link to 6.1.7.4 Well-Known Intrinsic Objects rather than the clause where the particular %Foo% is defined?

Hmm - I’m just saying that the syntax should link somewhere; i don’t have a strong opinion as to where.

Okay, well:

Every use of a well-known intrinsic already auto-links to the clause that defines it.

Ditto for the bulk of the not-well-known (NWK) intrinsics that the spec actually references (e.g. %Object.prototype% and %Function.prototype%).

I count 15 in-spec references to 11 NWK intrinsics that don't get auto-linked (e.g., 3 uses of %Array.prototype.values%). So there's room for improvement.

And then there are scads of NWK intrinsics that wouldn't get auto-linked if they were referenced, but the spec never does (e.g. %String.prototype.at%).

ok, so maybe usage should link to definition, but the definition site should link to the section explaining the syntax?

So, e.g.,
This function is the <dfn>%ThrowTypeError%</dfn> intrinsic object.
could retain the redundant "intrinsic object", but that phrase could auto-link to 6.1.7.4.

jmdyck · 2021-11-29T04:08:06Z

What about the Promise statics?

If the editors agree they should be referred to as 'methods', I'll make that change.

ExE-Boss · 2021-11-29T07:34:28Z

I think we should extend structured headers to also support built‑in function objects.

bakkot · 2021-11-29T07:37:10Z

The general approach for structured headers has been to first decide on a regular form for the prose and only then support generating it from a structured header.

jmdyck · 2021-11-29T17:31:46Z

I'm not sure that intrinsic functions have enough commonality (factorable stuff) to make structured headers worthwhile. (At least, not in the way that abstract operations have them.)

One thing we could do (that's roughly in that direction) would be to identify things that can appear in the defining clause of an intrinsic function, and then say how and in what order they should appear. E.g., here are some things in a possible order (note that I'm not saying much about their form):

optional: A non-normative summary of the function's behavior. (See my comment above re current variability in how and where these appear.) This could include prose about what the parameters mean and what the function returns.
A normative statement of the function's behavior (which is usually an <emu-alg>, but might instead be some prose constraints, or "it's like this other function, but different").
optional: Giving the percent-delimited name for this intrinsic.
optional: Definitions of the function's properties.
optional: Various kinds of notes.

It's possible that the ecmarkup tool could recognize these things and enforce their order + form, but I kind of doubt that it will be reading a structured header and generating boilerplate.

jmdyck · 2022-01-10T22:20:01Z

(force-pushed to resolve merge conflicts)

jmdyck · 2022-02-19T05:25:16Z

I'd be willing to modify intrinsics prose as suggested above, but it would need some direction from editors.

I'm not saying such changes would need to be incorporated into this PR, this is just where the idea came up.

jmdyck · 2022-03-30T00:31:26Z

(force-pushed to resolve merge conflicts)

jmdyck · 2022-06-02T18:43:03Z

(force-pushed to resolve merge conflicts)

bakkot · 2022-06-25T21:38:57Z

spec.html

@@ -31148,14 +31164,15 @@ <h1>Number.prototype.toFixed ( _fractionDigits_ )</h1>

      <emu-clause id="sec-number.prototype.tolocalestring">
        <h1>Number.prototype.toLocaleString ( [ _reserved1_ [ , _reserved2_ ] ] )</h1>
-        <p>An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement the `Number.prototype.toLocaleString` method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of the `toLocaleString` method is used.</p>
-        <p>Produces a String value that represents this Number value formatted according to the conventions of the host environment's current locale. This function is implementation-defined, and it is permissible, but not encouraged, for it to return the same thing as `toString`.</p>
+        <p>An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used.</p>


Suggested change

An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used.

An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used:

Maybe? The original lacked this as well, but I think the wording tweak makes it a little less clear, and the colon makes it more clear.

bakkot · 2022-06-25T21:39:36Z

spec.html

@@ -31329,8 +31346,8 @@ <h1>BigInt.prototype.constructor</h1>

      <emu-clause id="sec-bigint.prototype.tolocalestring">
        <h1>BigInt.prototype.toLocaleString ( [ _reserved1_ [ , _reserved2_ ] ] )</h1>
-        <p>An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement the `BigInt.prototype.toLocaleString` method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of the `toLocaleString` method is used.</p>
-        <p>Produces a String value that represents this BigInt value formatted according to the conventions of the host environment's current locale. This function is implementation-defined, and it is permissible, but not encouraged, for it to return the same thing as `toString`.</p>
+        <p>An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used.</p>


Suggested change

An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used.

An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used:

as above.

bakkot · 2022-06-25T21:41:53Z

spec.html

@@ -31610,7 +31627,7 @@ <h1>Math.ceil ( _x_ )</h1>

      <emu-clause id="sec-math.clz32">
        <h1>Math.clz32 ( _x_ )</h1>


I'm amused that almost all of the math functions get descriptions but clz32 does not, as if readers might need an explanation for what sqrt means but can be expected to understand clz32 without elaboration. Doesn't need to be changed now, though.

bakkot · 2022-06-25T21:45:19Z

spec.html

        <emu-note>
-          <p>If _sec_ is not present, this method behaves as if _sec_ was present with the value `getUTCSeconds()`. If _ms_ is not present, it function behaves as if _ms_ was present with the value return by `getUTCMilliseconds()`.</p>


That typo goes back to es2015, geeze.

bakkot · 2022-06-25T21:45:56Z

spec.html

        <p>The meaning of the optional parameters to this method are defined in the ECMA-402 specification; implementations that do not include ECMA-402 support must not use those parameter positions for anything else.</p>
      </emu-clause>

      <emu-clause id="sec-date.prototype.tolocaletimestring">
        <h1>Date.prototype.toLocaleTimeString ( [ _reserved1_ [ , _reserved2_ ] ] )</h1>
-        <p>An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement the `Date.prototype.toLocaleTimeString` method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of the `toLocaleTimeString` method is used.</p>
-        <p>This function returns a String value. The contents of the String are implementation-defined, but are intended to represent the &ldquo;time&rdquo; portion of the Date in the current time zone in a convenient, human-readable form that corresponds to the conventions of the host environment's current locale.</p>
+        <p>An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used.</p>


Suggested change

An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used.

An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used:

bakkot · 2022-06-25T21:47:46Z

spec.html

-        <p>An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement the `localeCompare` method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of the `localeCompare` method is used.</p>
-        <p>When the `localeCompare` method is called with argument _that_, it returns a Number other than *NaN* representing the result of an implementation-defined locale-sensitive String comparison of the *this* value (converted to a String _S_) with _that_ (converted to a String _thatValue_). The result is intended to correspond with a sort order of String values according to conventions of the host environment's current locale, and will be negative when _S_ is ordered before _thatValue_, positive when _S_ is ordered after _thatValue_, and zero in all other cases (representing no relative ordering between _S_ and _thatValue_).</p>
-        <p>Before performing the comparisons, the following steps are performed to prepare the Strings:</p>
+        <p>An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used.</p>


Suggested change

An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used.

An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used:

bakkot · 2022-06-25T21:48:58Z

spec.html

-        <p>An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement the `toLocaleLowerCase` method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of the `toLocaleLowerCase` method is used.</p>
-        <p>This function interprets a String value as a sequence of UTF-16 encoded code points, as described in <emu-xref href="#sec-ecmascript-language-types-string-type"></emu-xref>.</p>
-        <p>This function works exactly the same as `toLowerCase` except that it is intended to yield a locale-sensitive result corresponding with conventions of the host environment's current locale. There will only be a difference in the few cases (such as Turkish) where the rules for that language conflict with the regular Unicode case mappings.</p>
+        <p>An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used.</p>


Suggested change

An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used.

An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used:

bakkot · 2022-06-25T22:07:06Z

spec.html

@@ -37953,9 +37977,9 @@ <h1>
      <emu-clause id="sec-array.prototype.splice">
        <h1>Array.prototype.splice ( _start_, _deleteCount_, ..._items_ )</h1>
        <emu-note>
-          <p>The _deleteCount_ elements of the array starting at integer index _start_ are replaced by the elements of _items_. An Array containing the deleted elements (if any) is returned.</p>
+          <p>This method deletes the _deleteCount_ elements of the array starting at integer index _start_, and replaces them with the elements of _items_. It returns an Array containing the deleted elements (if any).</p>


Suggested change

This method deletes the _deleteCount_ elements of the array starting at integer index _start_, and replaces them with the elements of _items_. It returns an Array containing the deleted elements (if any).

This method deletes the _deleteCount_ elements of the array starting at integer index _start_ and replaces them with the elements of _items_. It returns an Array containing the deleted elements (if any).

bakkot · 2022-06-25T22:10:09Z

spec.html

        </emu-note>
      </emu-clause>

      <emu-clause id="sec-array.prototype.tolocalestring">
        <h1>Array.prototype.toLocaleString ( [ _reserved1_ [ , _reserved2_ ] ] )</h1>
-        <p>An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement the `Array.prototype.toLocaleString` method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of the `toLocaleString` method is used.</p>
+        <p>An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used.</p>


Suggested change

An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used.

An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used:

michaelficarra · 2022-07-27T22:12:51Z

After @bakkot's review is addressed, this will be ready to merge.

jmdyck · 2022-07-31T03:29:43Z

Preserving commit messages before the big squash:

commit a2eb2acb2aaa825c60a6d902edda3d2c83b6d9cf

Normalize the use of "method" vs "function".

Most of the "method" -> "function" changes are for the Math.* functions.

See Issue #2576 for some discussion.

commit e7a0ed13f4814ab3fe6dd6679610b3f842a19350

Don't repeat the parameter list in the preamble (1)

The clause that defines an intrinsic function
(other than an acccessor function)
gives its parameter list in the clause heading.
Often, the preamble re-states the parameter list.
This commit (and the next) deletes those repeats.

(See Issue #2576 for justification.)

In this commit, we handle all the simple cases
where nothing is lost by deleting the repeat.

commit 2279fcf3a95f8655ca6f62e9de9b27fdd2bfa810

Don't repeat the parameter list in the preamble (2)

This commit has the same idea as the previous,
but it pulls out the cases where the restatement
includes something extra that you might want to retain.

commit acd77713ea0a47e43e7786819b3466ad94566313

Consistify the "following steps" phrasing (1)

The "following steps" sentence preceding the <emu-alg> element
comes in various forms:

"are taken"
    The following steps are taken:
    When X is called, the following steps are taken:

"are performed"
    The following steps are performed:

"performs"
    Specifically, it performs the following steps:
    When X is called it performs the following steps:
    When X is called, it performs the following steps:
    X performs the following steps:
    X performs the following steps when called:

This series of commits converts all of them to one form.
I picked the last one (which is what the ecmarkup tool
uses when generating preambles for abstract operations),
but you might want something different.

This commit converts the "are taken" forms.

commit 28ce2022af9c757fe11152a4eb7496fa1775b8ed

Consistify the "following steps" phrasing (2)

This commit converts the "steps are performed" form.

commit 8b6bf1a064695864731fea9fd78fcda9c2030193

Consistify the "following steps" phrasing (3)

This commit converts the "performs the following steps" forms.

commit daedb3d1c10b3756476847245517fadd8c548aee

Consistify the "following steps" phrasing (4)

This commit converts cases that use phrasing other than "the following steps".

commit b5bc598ccb1c0e62d82631dbb5eaeb5b94718dd8

Consistify the "following steps" phrasing (5)

Usually, the "following steps" sentence gets a <p> to itself.
This commit goes to the 29 cases where it doesn't,
and splits it off as a separate <p>.

(Except for accessor properties, which have their own way.)

commit 6847aec7d0e74a6dd2294dcc88b65a8ef9325d21

Elimininate "When"

Change two occurrences of:
    "When F is called, it returns X."
to:
    "F returns X."

commit 37bffb9d75ff0eb1209a15e8df276af1aa7c3081

Don't elide the subject

E.g., change:
    Returns X
to:
    This function returns X

commit dee880f788f93786874b1d2f02b6e84364e872c1

Consistify how a function's defining clause refers to it

Adopt the following rule:
Within the clause that defines an intrinsic function,
the prose will refer to it as "this function" (or "this method", as appropriate).

With the refinement that:
If the function is the subject of multiple contiguous paragraphs,
then the second and subsequent paragraphs can refer to it as simply "it".

(I've left some exceptions, all in <emu-note>s, I think.)

commit f8e6fd7ebe456e057da38cc6699b65dbe4e11cfe

Convert passive to active in preambles

In preambles, the spec usually uses the active voice.
This commit converts passive voice to active voice
when the implied subject is the function being defined.

(I leave the passive in a couple cases where I think it's clearer.)

commit e3f37437238f0e80ab030381518771ceedffce2d

Eliminate some occurrences of "is used to"

I.e., change occurrences of:
    "This function is used to do X"
to:
    "This function does X"

Function.prototype[@@hasInstance]: Delete "of an object _F_". Saying "the `@@hasInstance` method of an object _F_" suggests that `_F_` is the object whose `@@hasInstance` property is this method. But step 1 of the algorithm sets `_F_` to the *this* value, which needn't be that object, so the phrase is misleading. It looks like about a dozen phrases of this form came and went during the working drafts of ES6, but this particular occurrence survived. Number.prototype.toExponential and Number.prototype.toPrecision: Convert imperative to indicative. When describing functions (or operations, for that matter), the spec almost always uses the indicative mood, making statements about the function. (E.g., "This function does X.") But rarely it uses the imperative mood, telling the function how to behave. (E.g., "Do X.") This commit changes the preambles for these 2 functions from imperative to indicative. %TypedArray%.prototype.set: Rearrange the preamble. %TypedArray%.prototype.set used to be defined by two overloads, which caused some oddness in its preamble. When I converted it to have a single definition, I should have given it a more normal preamble. So this is a belated follow-up to PR tc39#2176. %TypedArray%.prototype.slice: Eliminate repetition. The preamble has both "The following steps are taken:" and "When the `slice` method is called, the following steps are taken:" Delete the former, for consistency with other %TypedArray% methods.

jmdyck · 2022-07-31T04:02:58Z

force-pushed to:

rebase to main;
amend to handle new findLast functions;
squash down to 2 commits;
address bakkot's review comments (in a fixup).

@bakkot: You should probably check the fixup commit.

I did the period-to-colon change in 3 places that you didn't suggest:

Date.prototype.toLocaleDateString
Date.prototype.toLocaleString
String.prototype.toLocaleUpperCase

because the context seemed the same,

and I also didn't do it one place you did suggest:

Array.prototype.toLocaleString

because the paragraph is followed by a Note, so ending the paragraph with colon seemed odd.

Function.prototype[@@hasInstance]: Delete "of an object _F_". Saying "the `@@hasInstance` method of an object _F_" suggests that `_F_` is the object whose `@@hasInstance` property is this method. But step 1 of the algorithm sets `_F_` to the *this* value, which needn't be that object, so the phrase is misleading. It looks like about a dozen phrases of this form came and went during the working drafts of ES6, but this particular occurrence survived. Number.prototype.toExponential and Number.prototype.toPrecision: Convert imperative to indicative. When describing functions (or operations, for that matter), the spec almost always uses the indicative mood, making statements about the function. (E.g., "This function does X.") But rarely it uses the imperative mood, telling the function how to behave. (E.g., "Do X.") This commit changes the preambles for these 2 functions from imperative to indicative. %TypedArray%.prototype.set: Rearrange the preamble. %TypedArray%.prototype.set used to be defined by two overloads, which caused some oddness in its preamble. When I converted it to have a single definition, I should have given it a more normal preamble. So this is a belated follow-up to PR tc39#2176. %TypedArray%.prototype.slice: Eliminate repetition. The preamble has both "The following steps are taken:" and "When the `slice` method is called, the following steps are taken:" Delete the former, for consistency with other %TypedArray% methods.

PR tc39#2711 overwrote some changes merged earlier: From PR tc39#2736: Change "calling agent" to "surrounding agent". From PR tc39#2592: Consistify the prose.

(Make it consistent with PR tc39#2592.)

(Make it consistent with PR tc39#2592)

jmdyck added the editorial change label Nov 29, 2021

ljharb reviewed Nov 29, 2021

View reviewed changes

jmdyck force-pushed the intrinsics_prose branch from 1c01a56 to 22c324a Compare January 10, 2022 22:19

jmdyck added the establishes editorial conventions label Feb 1, 2022

jmdyck force-pushed the intrinsics_prose branch from 22c324a to c66bdd8 Compare March 10, 2022 03:27

jmdyck mentioned this pull request Mar 11, 2022

Editorial: make introductions for built-in functions use consistent wording #2304

Closed

jmdyck force-pushed the intrinsics_prose branch from c66bdd8 to eb573c5 Compare March 18, 2022 03:16

jmdyck force-pushed the intrinsics_prose branch from eb573c5 to 37c392b Compare March 30, 2022 00:31

michaelficarra self-requested a review April 4, 2022 22:53

jmdyck force-pushed the intrinsics_prose branch from 37c392b to 8156427 Compare April 21, 2022 14:18

jmdyck mentioned this pull request May 25, 2022

Editorial: Improve consistency of referring to String values #2711

Merged

jmdyck force-pushed the intrinsics_prose branch from 8156427 to 2cdf8ea Compare June 2, 2022 18:42

michaelficarra added the editor call to be discussed in the next editor call label Jun 6, 2022

michaelficarra removed the editor call to be discussed in the next editor call label Jun 16, 2022

ptomato mentioned this pull request Jun 20, 2022

Editorial: Consistent prose for functions and methods tc39/proposal-temporal#2319

Merged

bakkot approved these changes Jun 25, 2022

View reviewed changes

jmdyck added a commit to jmdyck/ecma262 that referenced this pull request Jul 31, 2022

Editorial: Consistify prose for intrinsic functions (tc39#2592)

8cc21dc

jmdyck force-pushed the intrinsics_prose branch from 2cdf8ea to f77b46a Compare July 31, 2022 04:01

bakkot approved these changes Aug 1, 2022

View reviewed changes

bakkot added the ready to merge Editors believe this PR needs no further reviews, and is ready to land. label Aug 1, 2022

jmdyck added 2 commits August 3, 2022 11:44

Editorial: Consistify prose for intrinsic functions (tc39#2592)

2d3ecad

ljharb force-pushed the intrinsics_prose branch from f77b46a to 2d3ecad Compare August 3, 2022 18:45

ljharb merged commit 2d3ecad into tc39:main Aug 3, 2022

jmdyck mentioned this pull request Aug 5, 2022

Editorial: inconsistent prose for intrinsics #2576

Closed

jmdyck deleted the intrinsics_prose branch August 5, 2022 02:54

jmdyck mentioned this pull request Aug 5, 2022

definition of "method" #2846

Open

jmdyck mentioned this pull request Sep 8, 2022

Editorial: Tweak the parameter list of Function constructors #2902

Merged

jmdyck added a commit to jmdyck/ecma262 that referenced this pull request Jan 19, 2023

Use preamble conventions from PR tc39#2592

fa4546b

jmdyck added a commit to jmdyck/ecma262 that referenced this pull request Jan 24, 2023

Use preamble conventions from PR tc39#2592

ed62cf0

jmdyck mentioned this pull request Apr 20, 2024

Editorial: Consistify summaries for instrinsic functions #3315

Open

rbuckton pushed a commit to rbuckton/ecma262 that referenced this pull request May 23, 2024

Use preamble conventions from PR tc39#2592

8e5c252

rbuckton pushed a commit to rbuckton/ecma262 that referenced this pull request May 23, 2024

Use preamble conventions from PR tc39#2592

04b95ea

jmdyck mentioned this pull request Jun 27, 2024

Editorial: Convert @@ notation to intrinsics notation for well-known Symbols #1314

Merged

jmdyck added a commit to jmdyck/ecma262 that referenced this pull request Oct 19, 2024

Editorial: Fix Promise.try preamble

99a027a

(Make it consistent with PR tc39#2592.)

jmdyck added a commit to jmdyck/ecma262 that referenced this pull request Oct 19, 2024

Editorial: Fix Promise.try preamble

b8e10f3

(Make it consistent with PR tc39#2592.)

michaelficarra pushed a commit to jmdyck/ecma262 that referenced this pull request Oct 21, 2024

Editorial: Fix Promise.try preamble

8e38176

(Make it consistent with PR tc39#2592.)

ljharb pushed a commit to jmdyck/ecma262 that referenced this pull request Nov 8, 2024

Editorial: Fix Promise.try preamble (tc39#3454)

c4dc43c

(Make it consistent with PR tc39#2592)

kimjg1119 pushed a commit to kimjg1119/ecma262 that referenced this pull request Nov 20, 2024

Editorial: Fix Promise.try preamble (tc39#3454)

8ecb0c5

(Make it consistent with PR tc39#2592)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Editorial: Consistify prose for intrinsic functions #2592

Editorial: Consistify prose for intrinsic functions #2592

jmdyck commented Nov 29, 2021 •

edited

Loading

jmdyck commented Nov 29, 2021

ljharb commented Nov 29, 2021

ljharb Nov 29, 2021

jmdyck Nov 29, 2021

ljharb Nov 29, 2021

jmdyck Nov 29, 2021

ljharb Nov 29, 2021

jmdyck Nov 29, 2021

ljharb Nov 29, 2021

jmdyck Nov 29, 2021

jmdyck commented Nov 29, 2021

ExE-Boss commented Nov 29, 2021

bakkot commented Nov 29, 2021

jmdyck commented Nov 29, 2021

jmdyck commented Jan 10, 2022

jmdyck commented Feb 19, 2022

jmdyck commented Mar 30, 2022

jmdyck commented Jun 2, 2022

bakkot Jun 25, 2022

bakkot Jun 25, 2022

bakkot Jun 25, 2022

bakkot Jun 25, 2022

bakkot Jun 25, 2022

bakkot Jun 25, 2022

bakkot Jun 25, 2022

bakkot Jun 25, 2022

bakkot Jun 25, 2022

michaelficarra commented Jul 27, 2022

jmdyck commented Jul 31, 2022

jmdyck commented Jul 31, 2022 •

edited

Loading

	<p>An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used.</p>
	<p>An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement this method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of this method is used:</p>

		@@ -31610,7 +31627,7 @@ <h1>Math.ceil ( _x_ )</h1>

		<emu-clause id="sec-math.clz32">
		<h1>Math.clz32 ( _x_ )</h1>

		<emu-note>
		<p>If _sec_ is not present, this method behaves as if _sec_ was present with the value `getUTCSeconds()`. If _ms_ is not present, it function behaves as if _ms_ was present with the value return by `getUTCMilliseconds()`.</p>

	<p>This method deletes the _deleteCount_ elements of the array starting at integer index _start_, and replaces them with the elements of _items_. It returns an Array containing the deleted elements (if any).</p>
	<p>This method deletes the _deleteCount_ elements of the array starting at integer index _start_ and replaces them with the elements of _items_. It returns an Array containing the deleted elements (if any).</p>

Editorial: Consistify prose for intrinsic functions #2592

Editorial: Consistify prose for intrinsic functions #2592

Conversation

jmdyck commented Nov 29, 2021 • edited Loading

jmdyck commented Nov 29, 2021

ljharb commented Nov 29, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jmdyck commented Nov 29, 2021

ExE-Boss commented Nov 29, 2021

bakkot commented Nov 29, 2021

jmdyck commented Nov 29, 2021

jmdyck commented Jan 10, 2022

jmdyck commented Feb 19, 2022

jmdyck commented Mar 30, 2022

jmdyck commented Jun 2, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

michaelficarra commented Jul 27, 2022

jmdyck commented Jul 31, 2022

jmdyck commented Jul 31, 2022 • edited Loading

jmdyck commented Nov 29, 2021 •

edited

Loading

jmdyck commented Jul 31, 2022 •

edited

Loading