Rename RFC to PPC in the actual Proposed Perl Changes

book · rjbs · commit 6f8ceedb5454 · 2023-03-28T22:37:22.000-04:00
diff --git a/ppcs/ppc0001.md b/ppcs/ppc0001.md
diff --git a/ppcs/ppc0003.md b/ppcs/ppc0003.md
diff --git a/ppcs/ppc0004.md b/ppcs/ppc0004.md
@@ -27,7 +27,7 @@ as in this case, if the `operation` function throws an exception the teardown do
 
 It would be nice to offer a native core syntax for this common behaviour. A simple `defer { BLOCK }` syntax removes from the user any requirement to think about storing the guard object in a lexical variable, or worry about making sure it really does get released at the right time.
 
-This syntax has already been implemented as a CPAN module, [`Syntax::Keyword::Defer`](https://metacpan.org/pod/Syntax::Keyword::Defer). This RFC formalizes an attempt implement the same in core.
+This syntax has already been implemented as a CPAN module, [`Syntax::Keyword::Defer`](https://metacpan.org/pod/Syntax::Keyword::Defer). This PPC formalizes an attempt implement the same in core.
 
 ## Rationale
 
@@ -144,7 +144,7 @@ In this case, the caller will definitely see *an* exception thrown from the code
 
 The new syntax `defer { BLOCK }` is guarded by a lexical feature guard. A static analyser that is not aware of that feature guard would get confused into thinking this is indirect call syntax; though this is no worse than basically any other feature-guarded keyword that controls a block (e.g. `try/catch`).
 
-For easy compatibility on older Perl versions, the CPAN implementation already mentioned above can be used. If this RFC succeeds at adding it as core syntax, a `Feature::Compat::Defer` module can be created for it in the same style as [`Feature::Compat::Try`](https://metacpan.org/pod/Feature::Compat::Try).
+For easy compatibility on older Perl versions, the CPAN implementation already mentioned above can be used. If this PPC succeeds at adding it as core syntax, a `Feature::Compat::Defer` module can be created for it in the same style as [`Feature::Compat::Try`](https://metacpan.org/pod/Feature::Compat::Try).
 
 ## Security Implications
 
@@ -180,7 +180,7 @@ I'm not happy with the way I implemented it yet (don't look at how I abused an S
 
 ## Future Scope
 
-If this RFC becomes implemented, it naturally follows to enquire whether the same mechanism that powers it could be used to add a `finally` clause to the `try/catch` syntax added in Perl 5.34. This remains an open question: while it doesn't any new ability, is the added expressive power and familiarity some users will have enough to justify there now being two ways to write the same thing?
+If this PPC becomes implemented, it naturally follows to enquire whether the same mechanism that powers it could be used to add a `finally` clause to the `try/catch` syntax added in Perl 5.34. This remains an open question: while it doesn't any new ability, is the added expressive power and familiarity some users will have enough to justify there now being two ways to write the same thing?
 
 Additionally, once `defer` exists and if core exceptions ever gain some sort of metadata or object-like representation beyond simple strings, then the double-exception case mentioned above can be addressed.
 
diff --git a/ppcs/ppc0005.md b/ppcs/ppc0005.md
@@ -4,13 +4,13 @@
 
     Author:  Ricardo Signes <rjbs@semiotic.systems>
     Sponsor: Ricardo Signes <rjbs@semiotic.systems>
-    ID:      RFC 0005
+    ID:      0005
     Status:  Rejected
 
 ## Abstract
 
 Perl's slice syntax lets the programmer get at a subset of values or key/value
-pairs in a hash or array.  This RFC proposes a syntax get a slice that contains
+pairs in a hash or array.  This PPC proposes a syntax get a slice that contains
 the complete set of values or key/values in the hash or array.
 
 ## Motivation
@@ -36,7 +36,7 @@ Note, too, the sigil variance.
 `%hash` in list context evaluates to a list of pairs, while `@array` in list
 context evalutes to the values.  There's a means to get the values of a hash
 with `values`, but no existing built-in for (say) `kv @array`.  Rather than
-propose adding a `kv`, which would only be useful on arrays, this RFC proposes
+propose adding a `kv`, which would only be useful on arrays, this PPC proposes
 adding a type of slice that includes all keys and values.
 
     %hash{*};   # equivalent to %hash{ keys %hash }
diff --git a/ppcs/ppc0006.md b/ppcs/ppc0006.md
@@ -9,7 +9,7 @@
 
 ## Abstract
 
-This RFC proposes a new built-in, "load\_module", to load modules by module
+This PPC proposes a new built-in, "load\_module", to load modules by module
 name (rather than filename) at runtime.
 
 ## Motivation
@@ -24,7 +24,7 @@ switch from using loader A to loader B."
 
 ## Rationale
 
-This RFC proposes exactly one behavior:  load a named module by module name or
+This PPC proposes exactly one behavior:  load a named module by module name or
 die trying.  Putting this in the core should allow using exactly the same
 loading logic as the core uses.  Avoiding any further behaviors or add-ons
 eliminates argument about what or how.
@@ -50,7 +50,7 @@ C<load_module> is only available when requested.
 
 Note:  The "how" of "when requested" is to be determined.  If implemented
 today, it would be provided behind "use feature".  [Current p5p
-discussion](https://github.com/Perl/RFCs/blob/master/rfcs/rfc0009.md) suggests
+discussion](https://github.com/Perl/PPCs/blob/master/ppcs/ppc0009.md) suggests
 that in the future it would be imported with std.pm or builtin.pm.
 
 ## Backwards Compatibility
@@ -82,7 +82,7 @@ for my $module (keys $config->{prereq}->%*) {
 
 ## Prototype Implementation
 
-Numerous prototype implementations exist, in effect.  This RFC is the request
+Numerous prototype implementations exist, in effect.  This PPC is the request
 to build the real deal.
 
 ## Future Scope
@@ -93,7 +93,7 @@ differentiation between failure to find the file, failure to compile, and other
 errors.
 
 These problems already exist with `use` and `require`.  Addressing them through
-more clearly-defined exceptions has been proposed in the past, and this RFC has
+more clearly-defined exceptions has been proposed in the past, and this PPC has
 not attempted to fix them just for `load_module`.  Instead, a future fix should
 address all at once.
 
diff --git a/ppcs/ppc0007.md b/ppcs/ppc0007.md
@@ -9,7 +9,7 @@
 
 ## Abstract
 
-This RFC proposes a new pragma, `source::encoding`, to indicate the encoding of
+This PPC proposes a new pragma, `source::encoding`, to indicate the encoding of
 the source document.
 
 ## Motivation
diff --git a/ppcs/ppc0008.md b/ppcs/ppc0008.md
@@ -13,7 +13,7 @@ Add to regular (defined and non-referential) scalars the ability to track whethe
 
 ## Motivation
 
-Language interoperability concerns sometimes lead to situations where it is necessary to represent typed data - such as strings or numbers - in a way that can be reliably distinguished. Elsewhere in Perl there are attempts to add this distinction. This RFC attempts to address how to handle values of a boolean type; values that represent a simple true-or-false nature.
+Language interoperability concerns sometimes lead to situations where it is necessary to represent typed data - such as strings or numbers - in a way that can be reliably distinguished. Elsewhere in Perl there are attempts to add this distinction. This PPC attempts to address how to handle values of a boolean type; values that represent a simple true-or-false nature.
 
 For example, JSON and MsgPack are commonly-encountered serialisation formats that Perl can generate and parse, though in both cases while the formats themselves can represent boolean truth values distinctly from numbers or strings, perl cannot preserve that distinction. Compare this to some other languages popular at the moment:
 
@@ -73,7 +73,7 @@ For creating such values, in many cases it is sufficient to simply use any of th
 my $sv = 4 > 5;   # The $sv now has SvIsBOOL
 ```
 
-It may be considered useful to provide two new zero-arity functions, `true` and `false`, to explicitly create these values (which are at least a little more obvious in intent than the equivalent `!!1` and `!!0`). These can be requested from the `builtin` module (RFC 0009):
+It may be considered useful to provide two new zero-arity functions, `true` and `false`, to explicitly create these values (which are at least a little more obvious in intent than the equivalent `!!1` and `!!0`). These can be requested from the `builtin` module (PPC 0009):
 
 ```perl
 use builtin 'true', 'false';
@@ -102,7 +102,7 @@ I accept that this is the weakest part of this suggestion so far, and welcome co
 
 There are not expected to be any backwards compatiblity problems with this proposal. At the interpreter level, extra information is being added to certain SV values, without changing the meaning of any existing information currently stored. Code that is unaware of the new semantics will continue to see existing values unaltered.
 
-Likewise at the Perl syntax level, the only new functionality being added consists of new functions in the `builtin` namespace (RFC 0009).
+Likewise at the Perl syntax level, the only new functionality being added consists of new functions in the `builtin` namespace (PPC 0009).
 
 ## Security Implications
 
diff --git a/ppcs/ppc0009.md b/ppcs/ppc0009.md
@@ -38,7 +38,7 @@ or
 say "The reference type of ref is ", builtin::reftype($ref);
 ```
 
-**Note:** This proposal largely concerns itself with the overal *mechanism* used to provide these functions, and expressly does not go into a full detailed list of individual proposed functions that ought to be provided. A short list is given containing a few likely candidates to start with, in order to experiment with the overall idea. Once found stable, it is expected that more functions can be added on a case-by-case basis; perhaps by using the RFC process or not, as individual cases require. In any case, it is anticipated that this list would be maintained on an ongoing basis as the language continues to evolve, with more functions being added at every release.
+**Note:** This proposal largely concerns itself with the overal *mechanism* used to provide these functions, and expressly does not go into a full detailed list of individual proposed functions that ought to be provided. A short list is given containing a few likely candidates to start with, in order to experiment with the overall idea. Once found stable, it is expected that more functions can be added on a case-by-case basis; perhaps by using the PPC process or not, as individual cases require. In any case, it is anticipated that this list would be maintained on an ongoing basis as the language continues to evolve, with more functions being added at every release.
 
 ## Rationale
 
@@ -139,7 +139,7 @@ As this proposal does not go into a full list of what specific functions might b
 
 * Some of the `POSIX` functions that act abstractly as in-memory data utilities, such as `ceil` and `floor`. I would not recommend adding the bulk of the operating system interaction functions from POSIX.
 
-* There are other RFCs or Pre-RFC discussions that suggest adding new named functions that would be good candidates for this module. They can be considered on their own merit, by reference to this RFC. At time of writing this may include new functions to handle core-supported boolean types (RFC 0008) or the new module-loading function (RFC 0006).
+* There are other PPCs or Pre-PPC discussions that suggest adding new named functions that would be good candidates for this module. They can be considered on their own merit, by reference to this PPC. At time of writing this may include new functions to handle core-supported boolean types (PPC 0008) or the new module-loading function (PPC 0006).
 
 * Once a stable set of functions is defined, consider creating version-numbered bundles in a similar theme to those provided by `feature.pm`:
 
@@ -194,17 +194,17 @@ This does initially seem attractive, until one considers the possibility that a
 
 ### Polyfill for Unavailable Semantics
 
-While not directly related to the question of how to provide builtin functions to new perls, by offering to provide a dual-life module on CPAN as a polyfill for older perl releases, the question arises on what to do if older perls cannot support the semantics of a provided function. The current suggestion of copying existing functions out of places like `Scalar::Util` does not cause this problem, but when we consider some of the additional RFCs we run into some more complex edge-cases.
+While not directly related to the question of how to provide builtin functions to new perls, by offering to provide a dual-life module on CPAN as a polyfill for older perl releases, the question arises on what to do if older perls cannot support the semantics of a provided function. The current suggestion of copying existing functions out of places like `Scalar::Util` does not cause this problem, but when we consider some of the additional PPCs we run into some more complex edge-cases.
 
-For example, RFC 0008 proposes adding new functions `true` and `false` to provide real language-level boolean values, and an `isbool` predicate function to enquire whether a given value has boolean intention. The first two can be easily provided on older perls, but polyfilling this latter function is not possible, because the question of "does this value have boolean intention?" is not a meaningful question to ask on such perls. There are a number of possible ways to handle this situation:
+For example, PPC 0008 proposes adding new functions `true` and `false` to provide real language-level boolean values, and an `isbool` predicate function to enquire whether a given value has boolean intention. The first two can be easily provided on older perls, but polyfilling this latter function is not possible, because the question of "does this value have boolean intention?" is not a meaningful question to ask on such perls. There are a number of possible ways to handle this situation:
 
 1. Refuse to import the symbol - `use builtin 'isbool'` would fail at compiletime
 
 2. Import, but refuse to invoke the function - `if( isbool $x ) { ... }` would throw an exception
 
 3. Give a meaningful but inaccurate answer - `isbool $x` would always return false, as the concept of "boolean intention" does not exist here
 
-Each of these could be argued as the correct behaviour. While it is not directly a question this RFC needs to answer, it is at least acknowledged that some added polyfill functions would have this question, and it would be encouraged that all polyfilled functions should attempt to act as consistently as reasonably possible in this regard.
+Each of these could be argued as the correct behaviour. While it is not directly a question this PPC needs to answer, it is at least acknowledged that some added polyfill functions would have this question, and it would be encouraged that all polyfilled functions should attempt to act as consistently as reasonably possible in this regard.
 
 ## Copyright
 
diff --git a/ppcs/ppc0011.md b/ppcs/ppc0011.md
@@ -60,7 +60,7 @@ Hopefully none.
 ## Rejected Ideas
 
 - Long flag, e.g. `--slurp`. Perl currently doesn't support long flags and
-  adding them would be beyond the scope of this RFC.
+  adding them would be beyond the scope of this PPC.
 
 - Alternative spellings of the flag, e.g. `-R`, `-o`. The author believes none
   of them are better or worse than `-g`. Unfortunately, the most natural choice,
diff --git a/ppcs/ppc0012.md b/ppcs/ppc0012.md
@@ -155,7 +155,7 @@ for example to see what the result is on CPAN.
 
 1. **Do Nothing**. Many people on p5p weren't aware of the existing capability
    (the compile flag), but on learning of its existence were keen to use it.
-   Extrapolating, the author of this RFC believes that a significant
+   Extrapolating, the author of this PPC believes that a significant
    percentage of Perl developers / users would happily make the trade-off
    (of no taint support, for improved performance), if they had the option.
 2. **Default to non-taint support**. I think people would rightly be surprised
@@ -182,7 +182,7 @@ for example to see what the result is on CPAN.
 * Should the sense of the question be "exclude" or "include"?
   Include is easier for people to understand, but results in a default of "y".
 
-I think these question have been resolved far enough here to make a decision on the RFC,
+I think these question have been resolved far enough here to make a decision on the PPC,
 and the final details of prompting etc can be left to the implementation.
 
 ## Copyright
diff --git a/ppcs/ppc0013.md b/ppcs/ppc0013.md
diff --git a/ppcs/ppc0014.md b/ppcs/ppc0014.md
@@ -110,9 +110,9 @@ variable use more friendly, but has various caveats as covered in the
 Spelling these variables like `$^ENGLISH_NAME` is not possible because
 variables of the form `$^E` exist. When interpolating, `"$^OS_ERROR"` is
 parsed as `"${^O}S_ERROR"`. If this brace-less form was still desired, this
-RFC would still be a prerequisite. When interpolating, a delimited form is
+PPC would still be a prerequisite. When interpolating, a delimited form is
 required to allow word characters to follow the variable. This delimited form
-would be the same `${^ENGLISH_NAME}` form proposed by this RFC.
+would be the same `${^ENGLISH_NAME}` form proposed by this PPC.
 
 `$*ENGLISH_NAME` has been proposed, but conflicts with glob dereferencing.
 Outside string interpolation, that variable syntax is currently invalid and
diff --git a/ppcs/ppc0015.md b/ppcs/ppc0015.md
@@ -80,7 +80,7 @@ This change will break backwards compatibility in two stable releases
 
 ### Known core / dual-life modules utilizing apostrophe as separator
 
-The following issues are slowly being sorted out independently of this RFC. 
+The following issues are slowly being sorted out independently of this PPC. 
 
 * ~~cpan/Term-Cap `isn't` in test [trivial to replace] https://github.com/jonathanstowe/Term-Cap/pull/13~~ [fixed]
 * ~~dist/PathTools `isn't` in test [trivial to replace] https://github.com/Perl/perl5/pull/19865~~ [fixed]
diff --git a/ppcs/ppc0016.md b/ppcs/ppc0016.md
@@ -9,7 +9,7 @@
 
 ## Abstract
 
-This RFC proposes `indexed`, a new builtin for interleaving a list of values
+This PPC proposes `indexed`, a new builtin for interleaving a list of values
 with their index in that list.  Among other things, this makes key/value
 iteration on arrays easy.
 
diff --git a/ppcs/ppc0017.md b/ppcs/ppc0017.md
@@ -9,7 +9,7 @@
 
 ## Abstract
 
-This RFC proposes adding new builtin functions created_as_string and
+This PPC proposes adding new builtin functions created_as_string and
 created_as_number for checking the original form of non-scalar references.
 Specifically, checking if a value was created as a string or a number. This
 is primarily meant for use by serializers.
diff --git a/ppcs/ppc0018.md b/ppcs/ppc0018.md
@@ -9,7 +9,7 @@
 
 ## Abstract
 
-This RFC proposes a feature which, when used, eliminates the need to end a Perl
+This PPC proposes a feature which, when used, eliminates the need to end a Perl
 module with the conventional "1" or other true value.
 
 ## Motivation
@@ -104,7 +104,7 @@ my $obj = (require Some::Object::Class)->new;
 However, per haarg:
 
 > Changing the return value of require seems like a separate issue from what
-> this RFC wants to address.
+> this PPC wants to address.
 >
 > If you wanted require to always return the same value, and for that value to
 > come from the file, you need a new location to store these values. This
@@ -113,7 +113,7 @@ However, per haarg:
 > very good idea.
 >
 > If you wanted require to always return the package name, it's a separate
-> issue from this RFC because that means ignoring the return value from the
+> issue from this PPC because that means ignoring the return value from the
 > file. It also presents a problem because require doesn't actually take
 > package names.  It takes file path fragments. Foo::Bar is translated to
 > "Foo/Bar.pm" at parse time. This would then need to be converted back to a
diff --git a/ppcs/ppc0019.md b/ppcs/ppc0019.md
@@ -4,7 +4,7 @@
 
     Author:  Ricardo Signes <rjbs@semiotic.systems>
     Sponsor: RJBS
-    ID:      RFC 0019
+    ID:      0019
     Status:  Draft
 
 ## Abstract
diff --git a/ppcs/ppc0020.md b/ppcs/ppc0020.md
@@ -103,7 +103,7 @@ Once a basic mechanism for lexical export exists in the language, it becomes tem
 
 Another possible idea becomes the thought of adding an `:export` attribute for functions and variables, bundling most of the export ability directly into the core language and avoiding most of the need to invoke an external module to do it.
 
-Both of these ideas are out of scope for this RFC, but would be made significantly easier by its completion.
+Both of these ideas are out of scope for this PPC, but would be made significantly easier by its completion.
 
 ## Rejected Ideas
 
diff --git a/ppcs/ppc0021.md b/ppcs/ppc0021.md
