develooper Front page | perl.perl5.porters | Postings from July 2018

Re: [perl #132142] Bleadperl v5.27.3-34-gf6107ca24b breaksMLEHMANN/AnyEvent-HTTP-2.23.tar.gz

Thread Previous | Thread Next
Andreas Koenig
July 29, 2018 17:30
Re: [perl #132142] Bleadperl v5.27.3-34-gf6107ca24b breaksMLEHMANN/AnyEvent-HTTP-2.23.tar.gz
Message ID:
>>>>> On Sun, 22 Jul 2018 16:36:24 +0100, Dave Mitchell <> said:

  > On Sun, Jul 22, 2018 at 04:28:36PM +0200, Andreas Koenig wrote:
 >> The point is that it is not only user-visible but actually user-tunable.
 >> Your arguments about not having user-visible effects collapse under
 >> these figures. What sense does it make to implement and announce an
 >> optimization that in fact requires cooperation from the user and then
 >> not to document it? And then to claim that it is intended as being
 >> non-user-visible?

  > Most optimisations I do are "user tunable" by that definition.

  > Did you know that if you do $a + $b, and ensure that $a and $b have only
  > ever contained integers (so for example have never held strings or been
  > used in a string context) then the addition is a lot faster? Is that
  > documented in perlop?  No. It is documented in perldelta? Quite possibly,
  > in the "Optimizations" section for whatever release I tweaked pp_add() et
  > al.

We have talked about it already. Perl is open source and as such the
documentation more often than not is the code itself. This is good
enough when everybody agrees. But when two developers interpret the
source differently, then we must find a balance on how we deal with
those differing interpretations. Then we must discuss what exactly we
consider the desired behaviour. It's one of the basic fundaments of how
open source works and why we engage in it.

  > I think the position you have taken is extreme, and if we used that
  > position to inform future perl bug fixes, perl would development would
  > come to a complete halt.

This is without doubt an interesting question. But watch out, there is a
bit of a grammatical twist in there and I guess it is because you edited
this sentence after having written it. Maybe it indicates, that you are
yourself in doubt about it? In general extremism allegations against
dissenters turn me off.

  > Really I am utterly confounded by the stance you are taking. Perl has a
  > strong ethos of maintaining backwards compatibility where reasonable, to
  > the extent that many many people shout at us for causing the stagnation of
  > perl 5.

Yes, but breaking stuff on CPAN without careful consideration is also
not what we need.

  > But we have never committed to maintaining 100% backwards
  > compatibility at all costs. Each decision is made on its own merits, with
  > a big dose of pragmatism.

Indeed. That's what I'm asking for: the appropriate amount of
pragmatism. On a case-by-case basis. A careful evaluation, how to
develop the language out of a conflict without brutally removing
valuable features.

  > As I have said before, I am willing to debate the pragmatic pros and cons
  > of whether it is better to make this change in behaviour.

I believe I have made a lot of my points. At least I have digged out the
original RT ticket that was leading to your commit. I find that in-place
sorting without changing any of the elements of an array is a feature
that we should not throw away.

  > What I am not prepared to accept, is that digging out a 14 year old
  > RT ticket, which at no no point proposes that weak references should
  > be preserved, has somehow bound us in perpetuity to preserve weak
  > references.

Your argument is very hard to parse for me, please explain what your
argument is:

- "digging": is it the fact that I was digging in the history what you
  find unacceptable? Are you claiming some right to be forgotten about
  old RT tickets? Or is digging an dirty inappropriate for language
  debate? What else could you have against digging?

- "a 14 year old": is it that the discussion is 14 years old? would it
  be more acceptable when the discussion would be more recent? Or older?
  How many years would be OK for you? And justified for which reason?
  Remember, that *my* argument also points out the 14 years. I'm
  arguing, it took 14 years until Tom Molesworth and Ilmari discovered
  this behaviour. For me it is a reason to treat it a feature that just
  has not been documented.

- "at no point proposes that weak references": the ticket said
  "in-place" and one reading of "in-place" means: leave each element
  alone. Leaving each element alone means of course not changing weak
  references. One could argue that the ticket was underspecified. But
  why would that be a justification to reject any different
  interpretation than your own? I know you disagree with my reading but
  then it's simply something we have to agree that we disagree.

- "perpetuity": what are you arguing against perpetuity? Has a language
  to be bent and redefined in all its appearances every day to be
  useful? Perpetuity is despite not being realistic, a blessing. For a
  programmer acting as-if it were for the perpetuity should be a
  liability, not a shame.

I repeat my quest: it is time to document existing behaviour for v5.8.4
- v5.28 and write tests that make sure we have it covered this time
around. In a second iteration I would hope somebody (hopefully with
decent language designing capabilities) comes up with something that
allows future users to choose which behaviour they want.


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