develooper Front page | perl.perl5.porters | Postings from December 2017

Re: We need a language design process.

Thread Previous | Thread Next
December 30, 2017 22:43
Re: We need a language design process.
Message ID:
On Sat, Dec 30 2017, Dan Book jotted:

> On Sat, Dec 30, 2017 at 3:36 PM, Ævar Arnfjörð Bjarmason <>
> wrote:
>> On Sat, Dec 30 2017, Father Chrysostomos jotted:
>> > Avar wrote:
>> >> I think in the future it makes sense to hold
>> >> ourselves to reviewing these features once they've been unchanged in say
>> >> 2 or 3 releases, and for the policy to say that experimental features
>> >> unchanged in 3 development cycles must either be promoted to
>> >> non-experimental, removed entirely, or have their semantics changed in
>> >> major ways.
>> >
>> > I don't think it makes sense.  If a feature is significantly flawed
>> > (and experimental) due to lack of tuits (e.g., refaliasing), do
>> > we have to make meaningless design changes to it to avoid having
>> > it yanked?
>> Not meaningless design changes, but to have some sort of schedule
>> (preferably enforced by code, i.e. as soon as we begun 5.25 we start to
>> warn/die) giving these experimental features an explicit expiry date.
>> The way perlpolicy is worded now, we could introduce an "experimental"
>> feature and not change its semantics for 20 years, and still call it
>> "experimental". That's absurd.
>> Consider the situation we're now in. We're about to release 5.28 and
>> we've chickened out on changing a supposedly "experimental" feature
>> mainly because it breaks stuff on CPAN.
>> This is the use it or lose it moment, either we change the semantics, or
>> we have to recognize that the "experimental" status perlpolicy talks
>> about doesn't exist at all, we're back to the pre-Jesse days of "change
>> perl and if people use it the semantics stay forever".
>> I'm not saying we have to take Zefram's patches as-is, but we should at
>> least change to something so that unless you specify:
>>     no about::to::deprecate "smartmatch";
>> We'll just die when we see given/when, to prepare people for "yes we're
>> *really* about to change this and we mean it".
> As mentioned before, this is a unique situation. A lot of the code using
> smartmatch, broken by these changes, was written on perls where it is not
> experimental. I do not think this is a good example of the community
> adopting an experimental feature to base policy changes on. However if you
> want to talk about the signatures feature that's a different story...

I'm not ignoring that, but I think my point still stands.

If we're going to play language police with perlpolicy.pod there's no
*explicit* mention of something that was previously a non-experimental
feature becoming experimental, so by that definition we can never change

However, immediately after defining what "experimental" means it talks
about how "deprecated" features may be removed in just two release

That's talking about removing a feature of perl that's never been
experimental, and has been there since 1987.

Do you think someone who wasn't involved in this particular argument
would resonable deduct:

 a) If something was a feature of perl in 1987 and was never marked as
    experimental, we might remove it in two release cycles.

 b) If something was a feature of perl in 1987 but was subsequently
    marked as experimental it can never be removed.

Or, do you think, as I read this:

 c) <same as a) above>

 d) If something was marked as experimental it doesn't matter that it
    was non-experimental before, we can mark anything experimental, if
    we're willing to deprecate and remove things things that were never
    experimental, it stands to reason that we'll deprecate and remove
    things that we've given you the extra grace perid of marking them as
    experimental for several release cycles before removing them.

I think going for a) and b) instead of c) and d) would be absurd,
clearly that's not what's meant by what's spelled out in perlpolicy
(although we should update the document to be clear about this).

Why would we give more of a grace period to things that have never even
warned "this is experimental" than things that haven't?

Which is not to endorse Zefram's patches to given/when (I haven't read
them in enough detail), but from from my reading of the threads over the
past few days the reasons for why they got revert wouldn't apply if it
was a new feature being added to perl today.

So it's really a case of us being too chickenshit to enforce our
explicitly established policy.

Which is not to say that I don't see the argument that most perl users
are never doing to read "perldoc perlpolicy", but if we're going to use
"it breaks CPAN" as a quantifiable metric over perlpolicy.pod, we should
change the policy to say that, and stop kidding ourselves about this
whole concept that we can introduce "experimental" stuff that we later

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About