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

Re: [perl #132760] Blead Breaks CPAN: YANICK/List-Lazy-0.3.0.tar.gz

Thread Previous | Thread Next
February 21, 2018 18:56
Re: [perl #132760] Blead Breaks CPAN: YANICK/List-Lazy-0.3.0.tar.gz
Message ID:
Dave Mitchell wrote:
>The more I think about this, the more I think that attributes should
>be allowed in *either* position, with a warning or croak for specific
>attributes found in the "wrong" location:

That would be a bad idea.  Although it would make it possible to put
:lvalue in the right place, possibility isn't enough.  The idea has most
of the other downsides of signatures preceding attributes.  It still
breaks the attribute abstraction, by forcing a visible distinction
between attributes that are permitted to follow signatures and those that
are not.  This distinction would have to be documented, and remembered
by programmers, who would no longer be able to just compose features in
an orthogonal manner.

Any attribute that has been classed as permitted to follow a signature
would be barred from ever being reimplemented in a way that alters
compilation of ordinary code.  That kind of reimplementation is an
option that is otherwise open to attributes.  In the likely event that
we later want to apply non-core attributes early enough to affect body
compilation, of course non-core attributes would labour under these
same burdens.  But further, we'd have to introduce some extra API for
non-core attributes to declare which category they fall into.

Under these conditions, we couldn't really say that signatures were
playing nicely with the existing stable feature of the :lvalue attribute.
They would certainly be impeding likely future developments.  This could
bar the blessing of signatures, in that form, as a stable feature.

Relative to the present situation of having signatures after all
attributes, the proposal for double helpings of attributes has only one
advantage, namely compatibility with the 5.22-5.26 version of signatures.
There certainly would be some benefit there, but it's quite limited,
because the compatibility is only with an experimental feature (marked as
such) in its early releases.  The same kind of compatibility benefit with
respect to 5.20 didn't dissuade people from moving signatures into the
wrong place for 5.22.  In this case, we must weigh against this temporary
gain the permanent damage that dual location would do to attributes,
as described above.

The balancing exercise is easy: compatibility that was disclaimed can't
outweigh long-term language coherence.  It is fortunate that we had
the formalised concept of experimental features in time for signatures,
in order to make it this easy.


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