Front page | perl.perl5.porters |
Postings from December 2017
Re: We need a language design process.
From: Ævar Arnfjörð Bjarmason
December 31, 2017 00:09
Re: We need a language design process.
Message ID: email@example.com
On Sat, Dec 30 2017, Tomasz Konojacki jotted:
> On Sun, 31 Dec 2017 00:37:56 +0100
> Ævar Arnfjörð Bjarmason <firstname.lastname@example.org> wrote:
>> Okey, then we patch perlpolicy.pod to say:
>> diff --git a/pod/perlpolicy.pod b/pod/perlpolicy.pod
>> index 6c57238eac..dfcf0432f6 100644
>> --- a/pod/perlpolicy.pod
>> +++ b/pod/perlpolicy.pod
>> @@ -248,6 +248,12 @@ no longer ship with Perl, but will continue to be available on CPAN.
>> +=head1 CAVEATS
>> +Oh and by they way, if something's sufficiently complex or widely
>> +used, forget about everything we mentioned about
>> +experimental/deprecated/etc. above, it's staying, B<forever>.
>> =head1 MAINTENANCE BRANCHES
>> New releases of maintenance branches should only contain changes that fall into
>> Which, to be clear, is I'm not taking a particular stance on these
>> given/when changes, but saying that we should decide, in general, how
>> the policy applies to changing such long-standing features.
>> Maybe the answer should be "it doesn't change", or maybe the answer
>> should be "suck it, take Zefram's patches", regardless of what any of us
>> think about those patches this discussion points to the fact that we
>> need to patch perlpolicy.pod to describe these situations more
> perlpolicy already covers that:
> Existing syntax and semantics should only be marked for destruction in very limited circumstances. If they are believed to be very rarely used, stand in the way of actual improvement to the Perl language or perl interpreter, and if affected code can be easily updated to continue working, they may be considered for removal. When in doubt, caution dictates that we will favor backward compatibility. When a feature is deprecated, a statement of reasoning describing the decision process will be posted, and a link to it will be provided in the relevant perldelta documents.
That's under a heading called "BACKWARD COMPATIBILITY AND DEPRECATION",
and "deprecated" is defined as "[marked] for two release cycles", which,
again I'm pointing out that you can play language police (not that I'm
accusing you of that) and say that given/when was never deprecated, but
we clearly never intended for "deprecated" to be a superset of
"experimental", but rather for "experimental" to be a a sort of subset
> Also, I didn't say we shouldn't touch smartmatch. To be frank, my point
> was that new smartmatch sucks and we need to rethink it.
I think we're in agreement there, but the general issue to be solved is:
What's to be done about Zefram's patches in light of perlpolicy.pod?
>> How are we going to handle the next new feature that gets introduced in
>> 5.30, gets marked as experimental in 5.40, and someone wants to change
>> in 5.48?
> I'm pretty sure we will never retroactively mark feature as
> experimental ever again.
What'll that mean? That per perlpolicy.pod we'll mark it directly as
deprecated? And thus give users even fewer releases to notice that they
shouldn't be using them?
Let's say, as an extreme example, that I'd push a patch to perl.git to
change "print" to "outputstuff":
x) If I were to mark "print" as deprecated I'd have to wait from 5.28
y) You're saying (If I'm getting this right) "we'll never retroactively
mark af feature as experimental again", what does that mean? I view
that as an *extra* layer on top of "depecated", i.e. we'd add
"outputstuff" instead of "print" in 5.28, then warn, and it would be
an opt-in feature (via warning) until 5.32.
Only in 5.32 would we deprecate "print" and say "this is going
away", and finally remove it in 5.36.
How's that better for our users? You're just saying that they should be
given less notice of invasive changes.