Dual-life perl 5-or-7 code and prototypes - impossible?

TL;DR: I believe it impossible to write a dual-life module using
  function prototypes that works on both perl 5 and perl 7.


I have been experimenting with what it might be like to maintain a dual
perl5-and-7 module that uses prototypes on functions. Core's List::Util
would be a good candidate except it's all written in XS, so never mind.
Next on my list is List::UtilsBy.

Right now it has lots of code looking like

  sub sort_by(&@) { ... }

So, first off I trivially just rewrite all of those into

  sub sort_by :prototype(&@) { ... }

And hey presto, my module works fine on 5.20 onwards, and presumably 7.

Now all I have to do is handle the pre-5.20s, right? ;)

HAH!

  $ perl5.18.2 lib/List/UtilsBy.pm 
  Invalid CODE attribute: prototype(&@) at lib/List/UtilsBy.pm line 147.

So my first thought was to inject a MODIFY_CODE_ATTRIBUTES.

Simply put, this doesn't work. A naive attempt which invokes
Sub::Util::set_prototype silently has no side-effect - it doesn't warn
or fail, it just doesn't set the prototype. I haven't investigated why
yet, but I have a bug open:

  https://rt.cpan.org/Ticket/Display.html?id=132889

I think it's probably because MODIFY_CODE_ATTRIBUTES runs too early in 
the parser. I have to defer it until UNITCHECK time. See more code
above.

While that works, it produces lots of warnings:

  CODE package attribute may clash with future reserved word: prototype at lib/List/UtilsBy.pm line 147.

OK, well I can sortof fix that one too, by injecting a
`no warnings 'reserved'".

So the current code in List/UtilsBy.pm looks like:

BEGIN {
   if( $] < 5.020 ) {
      require Sub::Util; Sub::Util->VERSION( '1.40' );
      warnings->unimport( qw( reserved ) );

      my @prototypes;

      *MODIFY_CODE_ATTRIBUTES = sub {
         my ( $pkg, $code, @attrs ) = @_;

         my @ret;
         foreach my $attr ( @attrs ) {
            if( $attr =~ m/^prototype\((.*)\)$/ ) {
               my $prototype = "$1";
               push @prototypes, [ $code, $prototype ];
               next;
            }
            push @ret, $attr;
         }

         return @ret;
      };

      UNITCHECK {
         foreach ( @prototypes ) {
            my ( $code, $prototype ) = @$_;
            Sub::Util::set_prototype( $_->[1], $_->[0] );
         }
      }
   }
}

And note that there are two large problems still unaddressed here:

 1) This code has to suppress all "reserved" warnings, not just those
    relating to the :prototype attribute

 2) This code has to appear in List/UtilsBy.pm directly because of that
    UNITCHECK phaser. It would not be possible to inject this entire
    thing via a module.

Point 1 is a slight annoyance, but point 2 really is the killer. If
we're already worried about people having to copy lines of boilerplate
about "use strict; use warnings;" around the place I'd hate to have to
copy the above ~30 lines of code between every one of my
prototypes-using modules.

I had originally hoped to move all this code into a simple module we
could `use`:

   use Sub::Attribute::Prototype;

Such a module would be a no-op on 5.20+, and inject something like the
above code on earlier perls. But the presence of that UNITCHECK phaser
appears to make this impossible. I haven't investigated the RT bug
linked above yet, but I suspect it won't be an easy fix because of the
order in which operations happen. Operations that are already fixed in
the design of older perl interpreters; remember this is a pre-5.20 only
problem. Even if I do find a fix for that issue, it will likely need a
new version of the XS module, which adds a little annoyance but not
impossible. That still leaves unfixed the `reserved` warnings though.


Someone - please prove me wrong. Please demonstrate a way to write a
prototype-using module that will work nicely on perls older than 5.20,
and also on 7. I allege it cannot be done.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
6/27/2020 11:45:38 AM
perl.perl5.porters 48128 articles. 1 followers. Follow

30 Replies
33 Views

Similar Articles

[PageSpeed] 25

"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> writes:

> TL;DR: I believe it impossible to write a dual-life module using
>   function prototypes that works on both perl 5 and perl 7.

Almost...

>
> So my first thought was to inject a MODIFY_CODE_ATTRIBUTES.
>
> Simply put, this doesn't work. A naive attempt which invokes
> Sub::Util::set_prototype silently has no side-effect - it doesn't warn
> or fail, it just doesn't set the prototype. I haven't investigated why
> yet, but I have a bug open:
>
>   https://rt.cpan.org/Ticket/Display.html?id=132889
>
> I think it's probably because MODIFY_CODE_ATTRIBUTES runs too early in 
> the parser. I have to defer it until UNITCHECK time. See more code
> above.

attributes.pm says:

    The call to [the MODIFY_type_ATTRIBUTES] method is currently made
    during the processing of the declaration.  In particular, this means
    that a subroutine reference will probably be for an undefined
    subroutine, even if this declaration is actually part of the
    definition.

> While that works, it produces lots of warnings:
>
>   CODE package attribute may clash with future reserved word: prototype at lib/List/UtilsBy.pm line 147.
>
> OK, well I can sortof fix that one too, by injecting a
> `no warnings 'reserved'".
>
> So the current code in List/UtilsBy.pm looks like:
>
> BEGIN {
>    if( $] < 5.020 ) {
>       require Sub::Util; Sub::Util->VERSION( '1.40' );
>       warnings->unimport( qw( reserved ) );
>
>       my @prototypes;
>
>       *MODIFY_CODE_ATTRIBUTES = sub {
>          my ( $pkg, $code, @attrs ) = @_;
>
>          my @ret;
>          foreach my $attr ( @attrs ) {
>             if( $attr =~ m/^prototype\((.*)\)$/ ) {
>                my $prototype = "$1";
>                push @prototypes, [ $code, $prototype ];
>                next;
>             }
>             push @ret, $attr;
>          }
>
>          return @ret;
>       };
>
>       UNITCHECK {
>          foreach ( @prototypes ) {
>             my ( $code, $prototype ) = @$_;
>             Sub::Util::set_prototype( $_->[1], $_->[0] );
>          }
>       }
>    }
> }
>
> And note that there are two large problems still unaddressed here:
>
>  1) This code has to suppress all "reserved" warnings, not just those
>     relating to the :prototype attribute
>
>  2) This code has to appear in List/UtilsBy.pm directly because of that
>     UNITCHECK phaser. It would not be possible to inject this entire
>     thing via a module.

The B::CompilerPhase::Hook module lets you programmatically enqueue
phasers: https://metacpan.org/pod/B::CompilerPhase::Hook.

Sticking the above code in a Sub::Attribute::Prototype::import() and
replacing UNITCHECK { ... } with enqueue_UNICHECK(sub { ...}) works.

Hoewver, another issue is that because the prototype isn't set until
UNITCHECK time, it will not apply to calls in the same unit as the
prototyped sub is defined in, so this is really only useful for modules
that export subs, not scripts.

- ilmari
-- 
- Twitter seems more influential [than blogs] in the 'gets reported in
  the mainstream press' sense at least.               - Matt McLeod
- That'd be because the content of a tweet is easier to condense down
  to a mainstream media article.                      - Calle Dybedahl
0
ilmari
6/27/2020 6:29:42 PM
On Sat, 27 Jun 2020 19:29:42 +0100
ilmari@ilmari.org (Dagfinn Ilmari Manns=C3=A5ker) wrote:

> attributes.pm says:
>=20
>     The call to [the MODIFY_type_ATTRIBUTES] method is currently made
>     during the processing of the declaration.  In particular, this
> means that a subroutine reference will probably be for an undefined
>     subroutine, even if this declaration is actually part of the
>     definition.

Hrm; I don't suppose then any way we can work around that inside the XS
code of Sub::Util::set_prototype itself, if perl is only going to splat
over it anyway.

> >  1) This code has to suppress all "reserved" warnings, not just
> > those relating to the :prototype attribute

Any way to address this one?

> >  2) This code has to appear in List/UtilsBy.pm directly because of
> > that UNITCHECK phaser. It would not be possible to inject this
> > entire thing via a module. =20
>=20
> The B::CompilerPhase::Hook module lets you programmatically enqueue
> phasers: https://metacpan.org/pod/B::CompilerPhase::Hook.
>=20
> Sticking the above code in a Sub::Attribute::Prototype::import() and
> replacing UNITCHECK { ... } with enqueue_UNICHECK(sub { ...}) works.

Ahah, well that's progress. It is an out-of-core XS module, which might
be a bit of a hard sell for trying to make a compat. mechanism for
*every* prototype-using CPAN module to be using, but I can give it a go
and see how it works.

> Hoewver, another issue is that because the prototype isn't set until
> UNITCHECK time, it will not apply to calls in the same unit as the
> prototyped sub is defined in, so this is really only useful for
> modules that export subs, not scripts.

That's still a good start. I think in practice none of the
List::UtilsBy functions call each other, so it will work for my
use-case, and probably a decent fraction of prototype-using CPAN
modules. Some BIG LOUD WARNINGS can be put into the docs of such a
still-hypothetical Sub::Attribute::Prototype in any case.

--=20
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
6/27/2020 7:26:11 PM
On Sat, 27 Jun 2020 19:29:42 +0100
ilmari@ilmari.org (Dagfinn Ilmari Manns=C3=A5ker) wrote:

> The B::CompilerPhase::Hook module lets you programmatically enqueue
> phasers: https://metacpan.org/pod/B::CompilerPhase::Hook.
>=20
> Sticking the above code in a Sub::Attribute::Prototype::import() and
> replacing UNITCHECK { ... } with enqueue_UNICHECK(sub { ...}) works.

Ahyes :)

So armed with this knowledge I have now created

  https://metacpan.org/pod/Sub::Attribute::Prototype

> Hoewver, another issue is that because the prototype isn't set until
> UNITCHECK time, it will not apply to calls in the same unit as the
> prototyped sub is defined in, so this is really only useful for
> modules that export subs, not scripts.

Ahyes, an annoying caveat. That and the other two are noted in the docs:

  https://metacpan.org/pod/Sub::Attribute::Prototype#Caveats

Because of these limitations, I'm probably not even going to convert my
own modules (e.g. List::UtilsBy) into using this one yet. I'd welcome
anyone trying to help improve the situation and get rid of these
problems, but currently it seems I shall have to leave List::UtilsBy in
a 7-unsafe state.

--=20
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
6/29/2020 3:22:53 PM
On 29/6/20 17:22, Paul "LeoNerd" Evans wrote:
 > On Sat, 27 Jun 2020 19:29:42 +0100
 > ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) wrote:
 >
 >> The B::CompilerPhase::Hook module lets you programmatically enqueue
 >> phasers: https://metacpan.org/pod/B::CompilerPhase::Hook.
 >>
 >> Sticking the above code in a Sub::Attribute::Prototype::import() and
 >> replacing UNITCHECK { ... } with enqueue_UNICHECK(sub { ...}) works.
 >
 > Ahyes :)
 >
 > So armed with this knowledge I have now created
 >
 >    https://metacpan.org/pod/Sub::Attribute::Prototype
 >
 >> Hoewver, another issue is that because the prototype isn't set until
 >> UNITCHECK time, it will not apply to calls in the same unit as the
 >> prototyped sub is defined in, so this is really only useful for
 >> modules that export subs, not scripts.
 >
 > Ahyes, an annoying caveat. That and the other two are noted in the docs:
 >
 >    https://metacpan.org/pod/Sub::Attribute::Prototype#Caveats
 >
 > Because of these limitations, I'm probably not even going to convert my
 > own modules (e.g. List::UtilsBy) into using this one yet. I'd welcome
 > anyone trying to help improve the situation and get rid of these
 > problems, but currently it seems I shall have to leave List::UtilsBy in
 > a 7-unsafe state.
 >

Aren't you too focused in supporting the new subroutine attribute in 
older perls instead of just providing its functionality in some way?

For instance, it shouldn't be to difficult to write a package, say for 
instance, "sub::prototype", that sets the function prototype and works 
both under p5 and p7.

   sub foo {
      ...
   }
   use sub::prototype foo => "$";

   sub bar {
      ...
   }
   use sub::prototype bar => "\@"


And in sub/prototype.pm

   ...
   sub import {
     my ($pkg, $sub_name, $proto) = @_;
     my $sub = get_reference_to_sub_in_some_way($sub_name);
     Sub::Util::set_prototype($sub, $proto);
   }
0
sfandino
6/29/2020 4:40:18 PM
On Mon, 29 Jun 2020 18:40:18 +0200
Salvador Fandi=C3=B1o <sfandino@gmail.com> wrote:

> Aren't you too focused in supporting the new subroutine attribute in=20
> older perls instead of just providing its functionality in some way?
>=20
> For instance, it shouldn't be to difficult to write a package, say
> for instance, "sub::prototype", that sets the function prototype and
> works both under p5 and p7.
>=20
>    sub foo {
>       ...
>    }
>    use sub::prototype foo =3D> "$";
>=20
>    sub bar {
>       ...
>    }
>    use sub::prototype bar =3D> "\@"

Ohsure, that could work. But for that matter the following already
works right now on all versions of perl

  sub foo { ... }
  BEGIN { Sub::Util::set_prototype( "$", \&foo ); }

But is that really what we want to encourage new authors of perl code
to be writing?

If we preferred that form, why would we have designed the `:prototype`
attribute in the first place? My aim was to allow people to continue
writing what is valid and encouraged in both *current* perl 5.32 and
proposed perl 7.

--=20
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
6/29/2020 4:53:12 PM
On 29/6/20 18:53, Paul "LeoNerd" Evans wrote:
> On Mon, 29 Jun 2020 18:40:18 +0200
> Salvador Fandiño <sfandino@gmail.com> wrote:
> 
>> Aren't you too focused in supporting the new subroutine attribute in
>> older perls instead of just providing its functionality in some way?
>>
>> For instance, it shouldn't be to difficult to write a package, say
>> for instance, "sub::prototype", that sets the function prototype and
>> works both under p5 and p7.
>>
>>     sub foo {
>>        ...
>>     }
>>     use sub::prototype foo => "$";
>>
>>     sub bar {
>>        ...
>>     }
>>     use sub::prototype bar => "\@"
> 
> Ohsure, that could work. But for that matter the following already
> works right now on all versions of perl
> 
>    sub foo { ... }
>    BEGIN { Sub::Util::set_prototype( "$", \&foo ); }
> 
> But is that really what we want to encourage new authors of perl code
> to be writing?
> 
> If we preferred that form, why would we have designed the `:prototype`
> attribute in the first place? My aim was to allow people to continue
> writing what is valid and encouraged in both *current* perl 5.32 and
> proposed perl 7.

If I had understood correctly the aim behind p7, it is to get people to 
use the new features. Just the opposite of encouraging people to write 
code compatible with p5, right?

If you want to remain compatible with both perl5 and perl7, you are 
going to have the worst of both worlds. You would not be able to use 
"features" removed from perl7 neither would you be able to use the new 
features added.
0
sfandino
6/29/2020 5:13:42 PM
On Mon, 29 Jun 2020 19:13:42 +0200
Salvador Fandi=C3=B1o <sfandino@gmail.com> wrote:

> If you want to remain compatible with both perl5 and perl7, you are=20
> going to have the worst of both worlds. You would not be able to use=20
> "features" removed from perl7 neither would you be able to use the
> new features added.

I'm not looking for my code to use new features of perl 7. I'm looking
for it to install cleanly without breaking.

Right now it is impossible (outside of Sub::Attribute::Prototype or
other hackery) to write a .pm file using prototypes which will work
correctly on both perl 5 and perl 7.

--=20
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
6/29/2020 5:33:46 PM
On Mon, 29 Jun 2020 18:33:46 +0100
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> On Mon, 29 Jun 2020 19:13:42 +0200
> Salvador Fandiño <sfandino@gmail.com> wrote:
> 
> > If you want to remain compatible with both perl5 and perl7, you are 
> > going to have the worst of both worlds. You would not be able to use 
> > "features" removed from perl7 neither would you be able to use the
> > new features added.
> 
> I'm not looking for my code to use new features of perl 7. I'm looking
> for it to install cleanly without breaking.
> 
> Right now it is impossible (outside of Sub::Attribute::Prototype or
> other hackery) to write a .pm file using prototypes which will work
> correctly on both perl 5 and perl 7.

To clarify: "perl 5" in this case means "perl 5.18 or below".
0
me
6/29/2020 5:49:09 PM
On Mon, 29 Jun 2020 19:49:09 +0200
Tomasz Konojacki <me@xenu.pl> wrote:

> To clarify: "perl 5" in this case means "perl 5.18 or below".

True.

I do maintain a non-trivial number of "dual-life" and CPAN River-like
modules on CPAN which use prototypes, and I am definitely keen to
ensure they continue to work on 5.18 and before.

Right now List::UtilsBy has a *large* following of downstream users and
works perfectly fine even back as far as 5.8.1. It would be a great
disappointment to me if that stopped.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
6/29/2020 5:52:49 PM
On 06/29/2020 13:13, Salvador Fandi=C3=B1o wrote:
> If I had understood correctly the aim behind p7, it is to get people=20
> to use the new features. Just the opposite of encouraging people to=20
> write code compatible with p5, right?
>
> If you want to remain compatible with both perl5 and perl7, you are=20
> going to have the worst of both worlds. You would not be able to use=20
> "features" removed from perl7 neither would you be able to use the new=20
> features added.
This seems terrible.=C2=A0 It can't possibly be canon.=C2=A0 It implies a=
 7PAN=20
that is mutually exclusive from CPAN.=C2=A0 How are people going to navig=
ate=20
that?

--=20

End of message.
0
rcaputo
6/29/2020 6:16:14 PM
On Mon, Jun 29, 2020 at 8:17 PM Rocco Caputo <rcaputo@pobox.com> wrote:
> On 06/29/2020 13:13, Salvador Fandi=C3=B1o wrote:
> > If I had understood correctly the aim behind p7, it is to get people
> > to use the new features. Just the opposite of encouraging people to
> > write code compatible with p5, right?
> >
> > If you want to remain compatible with both perl5 and perl7, you are
> > going to have the worst of both worlds. You would not be able to use
> > "features" removed from perl7 neither would you be able to use the new
> > features added.
>
> This seems terrible.  It can't possibly be canon.  It implies a 7PAN
> that is mutually exclusive from CPAN.  How are people going to navigate
> that?

It does seem terrible indeed. One of the main lessons of the python2/3
transition is that the only way to make it happen seamlessly is to
enable people to be compatible with both, yet that's surprisingly
difficult as it stands right now.

Leon
0
fawaka
6/29/2020 11:33:26 PM
On Sat, 27 Jun 2020 at 23:45, Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> wrote:
>
> TL;DR: I believe it impossible to write a dual-life module using
>   function prototypes that works on both perl 5 and perl 7.

There may be an easier, and inherently more portable and compatible
option, assuming of course, perl7 never deprecates the ability to `no
feature qw(signatures)`

( in say, List::Utils )

BEGIN {
    if ( $] >= 7) {
        require feature;
        feature->unimport('signatures');
    }
}

I've synthetically demonstrated this currently works on perl5.

https://gist.github.com/kentfredric/875a5d2f9d56a7438669cbabfdc3b885

Surely I must have missed something obvious.
0
kentfredric
6/30/2020 7:56:00 PM
--000000000000ac63ae05a95d39a2
Content-Type: text/plain; charset="UTF-8"

On Tue., Jun. 30, 2020, 3:56 p.m. Kent Fredric, <kentfredric@gmail.com>
wrote:

> BEGIN {
>     if ( $] >= 7) {
>         require feature;
>         feature->unimport('signatures');
>     }
> }
>

By the way, simpler:

no if $] < 7, feature => qw( signatures );

--000000000000ac63ae05a95d39a2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Tue., Jun. 30, 2020, 3:56 p.m. Kent Fredric, &lt;<a=
 href=3D"mailto:kentfredric@gmail.com">kentfredric@gmail.com</a>&gt; wrote:=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
BEGIN {<br>
=C2=A0 =C2=A0 if ( $] &gt;=3D 7) {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 require feature;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 feature-&gt;unimport(&#39;signatures&#39;);<br>
=C2=A0 =C2=A0 }<br>
}<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>By the way, simpler:</div><div dir=3D"auto"><br></div><div dir=3D"auto">no=
 if $] &lt; 7, feature =3D&gt; qw( signatures );</div><div dir=3D"auto"><br=
></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
</blockquote></div></div></div>

--000000000000ac63ae05a95d39a2--
0
ikegami
7/1/2020 8:38:55 AM
On Wed, 1 Jul 2020 04:38:55 -0400
Eric Brine <ikegami@adaelis.com> wrote:

> > BEGIN {
> >     if ( $] >=3D 7) {
> >         require feature;
> >         feature->unimport('signatures');
> >     }
> > }
> > =20
>=20
> By the way, simpler:
>=20
> no if $] < 7, feature =3D> qw( signatures );

So what you're saying is that as a Perl 5 author, I have to guess what
features 7 is going to turn on so I can pre=C3=ABmptively opt out of them
before it comes?

What is Perl 8 going to turn on, or 9 ...?

This situation is surely ridiculous. I should not have to be predicting
what future versions will do that will be incompatible with my code so
I can ask them not to do it. Perl - any version of - shouldn't be doing
things I didn't explicitly ask it to do.

--=20
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/1/2020 10:10:20 AM
On Wed, 1 Jul 2020 at 22:10, Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> wrote:

> So what you're saying is that as a Perl 5 author, I have to guess what
> features 7 is going to turn on so I can pre=C3=ABmptively opt out of them
> before it comes?

Well, I guess you could also do:

 BEGIN {  %^H =3D ()  }

But at this rate, I half expect what that does to change one day too.

---
Kent

KENTNL - https://metacpan.org/author/KENTNL
0
kentfredric
7/1/2020 11:05:42 AM
There's also=20

no if $] >=3D 7 feature 'signatures';

I agree that's probably the best way to go. It's a technical debt that =
makes sense to put off for another day. The same goes for Test2 =
prototypes.

Todd

> On Jun 30, 2020, at 2:56 PM, Kent Fredric <kentfredric@gmail.com> =
wrote:
>=20
> On Sat, 27 Jun 2020 at 23:45, Paul "LeoNerd" Evans
> <leonerd@leonerd.org.uk> wrote:
>>=20
>> TL;DR: I believe it impossible to write a dual-life module using
>>  function prototypes that works on both perl 5 and perl 7.
>=20
> There may be an easier, and inherently more portable and compatible
> option, assuming of course, perl7 never deprecates the ability to `no
> feature qw(signatures)`
>=20
> ( in say, List::Utils )
>=20
> BEGIN {
>    if ( $] >=3D 7) {
>        require feature;
>        feature->unimport('signatures');
>    }
> }
>=20
> I've synthetically demonstrated this currently works on perl5.
>=20
> https://gist.github.com/kentfredric/875a5d2f9d56a7438669cbabfdc3b885
>=20
> Surely I must have missed something obvious.
0
toddr
7/1/2020 12:31:42 PM
On Wed, 1 Jul 2020 07:31:42 -0500
Todd Rinaldo <toddr@cpanel.net> wrote:

> I agree that's probably the best way to go. It's a technical debt
> that makes sense to put off for another day. The same goes for Test2
> prototypes.

Can we get you to say this again clearly, for the audience?

Are you actually saying that every Perl 5 module should now be actively
defending itself against a future Perl 7 from causing it breakage?

And it should be doing so by guessing that 'signatures' is the one and
only feature that needs to be disabled?

Are you going to promise that there won't be any more features in the
future that we'll also have to turn off?

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/1/2020 12:57:43 PM
--Apple-Mail=_2D77458A-9940-43DE-B3EB-3AA23A14EBCF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jul 1, 2020, at 7:57 AM, Paul LeoNerd Evans =
<leonerd@leonerd.org.uk> wrote:
>=20
> On Wed, 1 Jul 2020 07:31:42 -0500
> Todd Rinaldo <toddr@cpanel.net> wrote:
>=20
>> I agree that's probably the best way to go. It's a technical debt
>> that makes sense to put off for another day. The same goes for Test2
>> prototypes.
>=20
> Can we get you to say this again clearly, for the audience?

If you want me on record for something, I'll say I think dual life =
modules are a bad idea we had to do because perl 5 lasted so long. I'd =
rather we stop updating the CPAN version and keep what ships with Perl. =
I realize there are counter arguments to this and it's not the right =
time so =C2=AF\_(=E3=83=84)_/=C2=AF=20

> Are you actually saying that every Perl 5 module should now be =
actively
> defending itself against a future Perl 7 from causing it breakage?

IMO a dual life (especially something in dist) should be written to work =
with the version in blead. The long tail of having to code down to the =
supporting a perl written 20 years ago is unsustainable.=20

I would actually argue your statement is backward. We're not "defending =
against a future perl 7", we're "defending against a past perl 5".

> And it should be doing so by guessing that 'signatures' is the one and
> only feature that needs to be disabled?

It's not a guess right? you're using prototypes and the trick of =
rewriting the prototype means you can only be compatible back to perl =
5.18. So we have to do this instead.

no if $] >=3D 7 feature 'signatures';

> Are you going to promise that there won't be any more features in the
> future that we'll also have to turn off?

I'm not promising anything. It is my hope that some day in the future, =
enough stuff moves off of 5 that the v5 protocol just gets dropped from =
support. Is that next year or next century? No idea.=20

Todd=

--Apple-Mail=_2D77458A-9940-43DE-B3EB-3AA23A14EBCF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
Jul 1, 2020, at 7:57 AM, Paul LeoNerd Evans &lt;<a =
href=3D"mailto:leonerd@leonerd.org.uk" =
class=3D"">leonerd@leonerd.org.uk</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">On =
Wed, 1 Jul 2020 07:31:42 -0500<br class=3D"">Todd Rinaldo &lt;<a =
href=3D"mailto:toddr@cpanel.net" class=3D"">toddr@cpanel.net</a>&gt; =
wrote:<br class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">I=
 agree that's probably the best way to go. It's a technical debt<br =
class=3D"">that makes sense to put off for another day. The same goes =
for Test2<br class=3D"">prototypes.<br class=3D""></blockquote><br =
class=3D"">Can we get you to say this again clearly, for the =
audience?<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, =
0, 0);">If you want me on record for something, I'll say I think dual =
life modules are a bad idea we had to do because perl 5 lasted so long. =
I'd rather we stop updating the CPAN version and keep what ships with =
Perl. I realize there are counter arguments to this and it's not the =
right time so =C2=AF\_(=E3=83=84)_/=C2=AF&nbsp;</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br =
class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><div=
 class=3D"">Are you actually saying that every Perl 5 module should now =
be actively<br class=3D"">defending itself against a future Perl 7 from =
causing it breakage?<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>IMO a dual life (especially something in dist) =
should be written to work with the version in blead. The long tail of =
having to code down to the supporting a perl written 20 years ago is =
unsustainable.&nbsp;</div><div><br class=3D""></div><div>I would =
actually argue your statement is backward. We're not "defending against =
a future perl 7", we're "defending against a past perl 5".</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D"">And it should be doing so by guessing that 'signatures' is =
the one and<br class=3D"">only feature that needs to be disabled?<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>It's =
not a guess right? you're using prototypes and the trick of rewriting =
the prototype means you can only be compatible back to perl 5.18. So we =
have to do this instead.</div><div><span style=3D"caret-color: rgb(0, 0, =
0); color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px;" =
class=3D""><br class=3D""></span></div><div><span style=3D"caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Menlo-Regular; =
font-size: 11px;" class=3D"">no if $] &gt;=3D 7 feature =
'signatures';</span></div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div class=3D"">Are you going to promise that =
there won't be any more features in the<br class=3D"">future that we'll =
also have to turn off?<br class=3D""></div></div></blockquote><br =
class=3D""></div><div>I'm not promising anything. It is my hope that =
some day in the future, enough stuff moves off of 5 that the v5 protocol =
just gets dropped from support. Is that next year or next century? No =
idea.&nbsp;</div><div><br class=3D""></div><div>Todd</div></body></html>=

--Apple-Mail=_2D77458A-9940-43DE-B3EB-3AA23A14EBCF--
0
toddr
7/1/2020 6:26:21 PM
On Wed, 1 Jul 2020 13:26:21 -0500
Todd Rinaldo <toddr@cpanel.net> wrote:

> > On Jul 1, 2020, at 7:57 AM, Paul LeoNerd Evans
> > <leonerd@leonerd.org.uk> wrote:
> >=20
> > On Wed, 1 Jul 2020 07:31:42 -0500
> > Todd Rinaldo <toddr@cpanel.net> wrote:
> >  =20
> >> I agree that's probably the best way to go. It's a technical debt
> >> that makes sense to put off for another day. The same goes for
> >> Test2 prototypes. =20
> >=20
> > Can we get you to say this again clearly, for the audience? =20
>=20
> If you want me on record for something, I'll say I think dual life
> modules are a bad idea we had to do because perl 5 lasted so long.
> I'd rather we stop updating the CPAN version and keep what ships with
> Perl. I realize there are counter arguments to this and it's not the
> right time so =C2=AF\_(=E3=83=84)_/=C2=AF=20

I am not just talking about dual-life modules, but any module that
lives on CPAN. For example lets take my List::UtilsBy:

  https://metacpan.org/release/List-UtilsBy

Heavily used by a lot of other things down-river, and definitely
currently works before 5.20; probably back as far as 5.8 according to
the test matrix.

I have had an attempt at providing what I believe is my best effort at
fixing this; at providing something by which current perl 5 modules can
apply prototypes in a way that still works as valid perl 7 syntax:

  https://metacpan.org/pod/Sub::Attribute::Prototype

Given the huge Caveats section, I am hesitant to even apply this to any
of my own modules.

> > Are you actually saying that every Perl 5 module should now be
> > actively defending itself against a future Perl 7 from causing it
> > breakage? =20
>=20
> IMO a dual life (especially something in dist) should be written to
> work with the version in blead. The long tail of having to code down
> to the supporting a perl written 20 years ago is unsustainable.=20

Yeah; no great complaints from me there.

But again I'm not talking about dual-life modules; I'm talking about
all of CPAN.

Under this current plan of forcing 7-semantics on any perl module
without it asking so under "use VERSION" means that every single
prototypes-using CPAN module will now be broken trying to run on
perl 7. That's a lot of modules.

> > And it should be doing so by guessing that 'signatures' is the one
> > and only feature that needs to be disabled? =20
>=20
> It's not a guess right? you're using prototypes and the trick of
> rewriting the prototype means you can only be compatible back to perl
> 5.18. So we have to do this instead.
>=20
> no if $] >=3D 7 feature 'signatures';

And what if perl 7.2 decides that actually the keyword `sub` for
anonymous lambda functions is a bad idea, and we should all be spelling
it `lambda` instead? Does that mean now I have to go back around
everyone one of my CPAN modules that has ever created an anonymous
function and put

  no if $] >=3D 7.002, feature =3D> "lambda";

This is, again, guessing about what future things a future perl will
require my existing code to defend against.

> > Are you going to promise that there won't be any more features in
> > the future that we'll also have to turn off? =20
>=20
> I'm not promising anything. It is my hope that some day in the
> future, enough stuff moves off of 5 that the v5 protocol just gets
> dropped from support. Is that next year or next century? No idea.=20

Next century is far off. The announcement was that we'd have perl 7
"within a year, hopefully within six months". This isn't a century-away
question. This is me worrying about a lot of code that will break in
the next 6 to 12 months.

--=20
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/2/2020 3:42:13 PM
--0000000000008440c905a9781822
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Just a quick clarification about Sawyer's proposal. I thought he made this
clear in the talk, but you may have missed it.

In short, new features will be vetted in perl7 (and following) just as they
have in perl5, with feature guards. Any new behavior will be hidden behind
a feature guard and only available if you explicitly ask for it. The only
time a feature guard will be activated automatically is with a major
version update. So 7.2 would never automatically introduce feature
'lambda'. You would have to wait for v8 for that. (Except that renaming the
anonymous sub keyword to "lambda" is dumb and that'll never actually
happen. Cor is likely to be the big thing for v8, and that is not expected
to interfere with existing code anyway.)

We can expect a point release every year. How often would we see major
releases? Maybe every 3-5 years. They are supposed to enable features that
represent community consensus around best practices, and it'll take time
for those best practices to surface.

David

On Thu, Jul 2, 2020 at 11:42 AM Paul "LeoNerd" Evans <leonerd@leonerd.org.u=
k>
wrote:

> On Wed, 1 Jul 2020 13:26:21 -0500
> Todd Rinaldo <toddr@cpanel.net> wrote:
>
> > > On Jul 1, 2020, at 7:57 AM, Paul LeoNerd Evans
> > > <leonerd@leonerd.org.uk> wrote:
> > >
> > > On Wed, 1 Jul 2020 07:31:42 -0500
> > > Todd Rinaldo <toddr@cpanel.net> wrote:
> > >
> > >> I agree that's probably the best way to go. It's a technical debt
> > >> that makes sense to put off for another day. The same goes for
> > >> Test2 prototypes.
> > >
> > > Can we get you to say this again clearly, for the audience?
> >
> > If you want me on record for something, I'll say I think dual life
> > modules are a bad idea we had to do because perl 5 lasted so long.
> > I'd rather we stop updating the CPAN version and keep what ships with
> > Perl. I realize there are counter arguments to this and it's not the
> > right time so =C2=AF\_(=E3=83=84)_/=C2=AF
>
> I am not just talking about dual-life modules, but any module that
> lives on CPAN. For example lets take my List::UtilsBy:
>
>   https://metacpan.org/release/List-UtilsBy
>
> Heavily used by a lot of other things down-river, and definitely
> currently works before 5.20; probably back as far as 5.8 according to
> the test matrix.
>
> I have had an attempt at providing what I believe is my best effort at
> fixing this; at providing something by which current perl 5 modules can
> apply prototypes in a way that still works as valid perl 7 syntax:
>
>   https://metacpan.org/pod/Sub::Attribute::Prototype
>
> Given the huge Caveats section, I am hesitant to even apply this to any
> of my own modules.
>
> > > Are you actually saying that every Perl 5 module should now be
> > > actively defending itself against a future Perl 7 from causing it
> > > breakage?
> >
> > IMO a dual life (especially something in dist) should be written to
> > work with the version in blead. The long tail of having to code down
> > to the supporting a perl written 20 years ago is unsustainable.
>
> Yeah; no great complaints from me there.
>
> But again I'm not talking about dual-life modules; I'm talking about
> all of CPAN.
>
> Under this current plan of forcing 7-semantics on any perl module
> without it asking so under "use VERSION" means that every single
> prototypes-using CPAN module will now be broken trying to run on
> perl 7. That's a lot of modules.
>
> > > And it should be doing so by guessing that 'signatures' is the one
> > > and only feature that needs to be disabled?
> >
> > It's not a guess right? you're using prototypes and the trick of
> > rewriting the prototype means you can only be compatible back to perl
> > 5.18. So we have to do this instead.
> >
> > no if $] >=3D 7 feature 'signatures';
>
> And what if perl 7.2 decides that actually the keyword `sub` for
> anonymous lambda functions is a bad idea, and we should all be spelling
> it `lambda` instead? Does that mean now I have to go back around
> everyone one of my CPAN modules that has ever created an anonymous
> function and put
>
>   no if $] >=3D 7.002, feature =3D> "lambda";
>
> This is, again, guessing about what future things a future perl will
> require my existing code to defend against.
>
> > > Are you going to promise that there won't be any more features in
> > > the future that we'll also have to turn off?
> >
> > I'm not promising anything. It is my hope that some day in the
> > future, enough stuff moves off of 5 that the v5 protocol just gets
> > dropped from support. Is that next year or next century? No idea.
>
> Next century is far off. The announcement was that we'd have perl 7
> "within a year, hopefully within six months". This isn't a century-away
> question. This is me worrying about a lot of code that will break in
> the next 6 to 12 months.
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
>


--=20
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

--0000000000008440c905a9781822
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Just a quick clarification about Sawyer&#39;s proposal. I =
thought he made this clear in the talk, but you may have missed it.<div><br=
></div><div>In short, new features will be vetted in perl7 (and following) =
just as they have in perl5, with feature guards. Any new behavior will be h=
idden behind a feature guard and only available if you explicitly ask for i=
t. The only time a feature guard will be activated=C2=A0automatically is wi=
th a major version update. So 7.2 would never automatically introduce featu=
re &#39;lambda&#39;. You would have to wait for v8 for that. (Except that r=
enaming the anonymous sub keyword to &quot;lambda&quot; is dumb and that&#3=
9;ll never actually happen. Cor is likely to be the big thing for v8, and t=
hat is not expected to interfere with existing code anyway.)</div><div><br>=
</div><div>We can expect a point release every year. How often would we see=
 major releases? Maybe every 3-5 years. They are supposed to enable feature=
s that represent community consensus around best practices, and it&#39;ll t=
ake time for those best practices to surface.</div><div><br></div><div>Davi=
d</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Thu, Jul 2, 2020 at 11:42 AM Paul &quot;LeoNerd&quot; Evans &lt;<=
a href=3D"mailto:leonerd@leonerd.org.uk">leonerd@leonerd.org.uk</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 1 Ju=
l 2020 13:26:21 -0500<br>
Todd Rinaldo &lt;<a href=3D"mailto:toddr@cpanel.net" target=3D"_blank">todd=
r@cpanel.net</a>&gt; wrote:<br>
<br>
&gt; &gt; On Jul 1, 2020, at 7:57 AM, Paul LeoNerd Evans<br>
&gt; &gt; &lt;<a href=3D"mailto:leonerd@leonerd.org.uk" target=3D"_blank">l=
eonerd@leonerd.org.uk</a>&gt; wrote:<br>
&gt; &gt; <br>
&gt; &gt; On Wed, 1 Jul 2020 07:31:42 -0500<br>
&gt; &gt; Todd Rinaldo &lt;<a href=3D"mailto:toddr@cpanel.net" target=3D"_b=
lank">toddr@cpanel.net</a>&gt; wrote:<br>
&gt; &gt;=C2=A0 =C2=A0<br>
&gt; &gt;&gt; I agree that&#39;s probably the best way to go. It&#39;s a te=
chnical debt<br>
&gt; &gt;&gt; that makes sense to put off for another day. The same goes fo=
r<br>
&gt; &gt;&gt; Test2 prototypes.=C2=A0 <br>
&gt; &gt; <br>
&gt; &gt; Can we get you to say this again clearly, for the audience?=C2=A0=
 <br>
&gt; <br>
&gt; If you want me on record for something, I&#39;ll say I think dual life=
<br>
&gt; modules are a bad idea we had to do because perl 5 lasted so long.<br>
&gt; I&#39;d rather we stop updating the CPAN version and keep what ships w=
ith<br>
&gt; Perl. I realize there are counter arguments to this and it&#39;s not t=
he<br>
&gt; right time so =C2=AF\_(=E3=83=84)_/=C2=AF <br>
<br>
I am not just talking about dual-life modules, but any module that<br>
lives on CPAN. For example lets take my List::UtilsBy:<br>
<br>
=C2=A0 <a href=3D"https://metacpan.org/release/List-UtilsBy" rel=3D"norefer=
rer" target=3D"_blank">https://metacpan.org/release/List-UtilsBy</a><br>
<br>
Heavily used by a lot of other things down-river, and definitely<br>
currently works before 5.20; probably back as far as 5.8 according to<br>
the test matrix.<br>
<br>
I have had an attempt at providing what I believe is my best effort at<br>
fixing this; at providing something by which current perl 5 modules can<br>
apply prototypes in a way that still works as valid perl 7 syntax:<br>
<br>
=C2=A0 <a href=3D"https://metacpan.org/pod/Sub::Attribute::Prototype" rel=
=3D"noreferrer" target=3D"_blank">https://metacpan.org/pod/Sub::Attribute::=
Prototype</a><br>
<br>
Given the huge Caveats section, I am hesitant to even apply this to any<br>
of my own modules.<br>
<br>
&gt; &gt; Are you actually saying that every Perl 5 module should now be<br=
>
&gt; &gt; actively defending itself against a future Perl 7 from causing it=
<br>
&gt; &gt; breakage?=C2=A0 <br>
&gt; <br>
&gt; IMO a dual life (especially something in dist) should be written to<br=
>
&gt; work with the version in blead. The long tail of having to code down<b=
r>
&gt; to the supporting a perl written 20 years ago is unsustainable. <br>
<br>
Yeah; no great complaints from me there.<br>
<br>
But again I&#39;m not talking about dual-life modules; I&#39;m talking abou=
t<br>
all of CPAN.<br>
<br>
Under this current plan of forcing 7-semantics on any perl module<br>
without it asking so under &quot;use VERSION&quot; means that every single<=
br>
prototypes-using CPAN module will now be broken trying to run on<br>
perl 7. That&#39;s a lot of modules.<br>
<br>
&gt; &gt; And it should be doing so by guessing that &#39;signatures&#39; i=
s the one<br>
&gt; &gt; and only feature that needs to be disabled?=C2=A0 <br>
&gt; <br>
&gt; It&#39;s not a guess right? you&#39;re using prototypes and the trick =
of<br>
&gt; rewriting the prototype means you can only be compatible back to perl<=
br>
&gt; 5.18. So we have to do this instead.<br>
&gt; <br>
&gt; no if $] &gt;=3D 7 feature &#39;signatures&#39;;<br>
<br>
And what if perl 7.2 decides that actually the keyword `sub` for<br>
anonymous lambda functions is a bad idea, and we should all be spelling<br>
it `lambda` instead? Does that mean now I have to go back around<br>
everyone one of my CPAN modules that has ever created an anonymous<br>
function and put<br>
<br>
=C2=A0 no if $] &gt;=3D 7.002, feature =3D&gt; &quot;lambda&quot;;<br>
<br>
This is, again, guessing about what future things a future perl will<br>
require my existing code to defend against.<br>
<br>
&gt; &gt; Are you going to promise that there won&#39;t be any more feature=
s in<br>
&gt; &gt; the future that we&#39;ll also have to turn off?=C2=A0 <br>
&gt; <br>
&gt; I&#39;m not promising anything. It is my hope that some day in the<br>
&gt; future, enough stuff moves off of 5 that the v5 protocol just gets<br>
&gt; dropped from support. Is that next year or next century? No idea. <br>
<br>
Next century is far off. The announcement was that we&#39;d have perl 7<br>
&quot;within a year, hopefully within six months&quot;. This isn&#39;t a ce=
ntury-away<br>
question. This is me worrying about a lot of code that will break in<br>
the next 6 to 12 months.<br>
<br>
-- <br>
Paul &quot;LeoNerd&quot; Evans<br>
<br>
<a href=3D"mailto:leonerd@leonerd.org.uk" target=3D"_blank">leonerd@leonerd=
..org.uk</a>=C2=A0 =C2=A0 =C2=A0 |=C2=A0 <a href=3D"https://metacpan.org/aut=
hor/PEVANS" rel=3D"noreferrer" target=3D"_blank">https://metacpan.org/autho=
r/PEVANS</a><br>
<a href=3D"http://www.leonerd.org.uk/" rel=3D"noreferrer" target=3D"_blank"=
>http://www.leonerd.org.uk/</a>=C2=A0 |=C2=A0 <a href=3D"https://www.tindie=
..com/stores/leonerd/" rel=3D"noreferrer" target=3D"_blank">https://www.tind=
ie.com/stores/leonerd/</a><br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature">=C2=A0&quot;Debugging is twice as hard as writin=
g the code in the first place.<br>
 =C2=A0 Therefore, if you write the code as cleverly as possible, you are,<=
br>
 =C2=A0 by definition, not smart enough to debug it.&quot; -- Brian Kernigh=
an<br></div>

--0000000000008440c905a9781822--
0
dcmertens
7/2/2020 4:42:24 PM
--0000000000006e82b105a97864c6
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 2, 2020 at 12:42 PM David Mertens <dcmertens.perl@gmail.com>
wrote:

> [...]
> We can expect a point release every year. How often would we see major
> releases? Maybe every 3-5 years. They are supposed to enable features that
> represent community consensus around best practices, and it'll take time
> for those best practices to surface.
>
>
If the Perl community has taught me anything it's consensus building takes
*way* longer than 3-5 years. Moose is now 14 years old and based on the
conversations around Cor there is still not a full consensus about the need
for a core object system beyond bless(), and we're just barely (say the
last 3-5 years) into a majority consensus that Moose is probably a
reasonably good idea as long as you remove about 50% of it, without a real
agreement on which 50% should be removed.

-Chris

--0000000000006e82b105a97864c6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jul 2, 2020 at 12:42 PM David=
 Mertens &lt;<a href=3D"mailto:dcmertens.perl@gmail.com">dcmertens.perl@gma=
il.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr">[...]<div>We can expect a point release every year. =
How often would we see major releases? Maybe every 3-5 years. They are supp=
osed to enable features that represent community consensus around best prac=
tices, and it&#39;ll take time for those best practices to surface.</div><b=
r></div></blockquote><div><br></div><div>If the Perl community has taught m=
e anything it&#39;s consensus building takes *way* longer than 3-5 years. M=
oose is now 14 years old and based on the conversations around Cor there is=
 still not a full consensus about the need for a core object system beyond =
bless(), and we&#39;re just barely (say the last 3-5 years) into a majority=
 consensus that Moose is probably a reasonably good idea as long as you rem=
ove about 50% of it, without a real agreement on which 50% should be remove=
d. <br></div></div><div class=3D"gmail_quote"><br></div><div class=3D"gmail=
_quote">-Chris<br></div></div>

--0000000000006e82b105a97864c6--
0
chris
7/2/2020 5:03:37 PM
On Fri, 3 Jul 2020 at 05:03, Chris Prather <chris@prather.org> wrote:
>
>
> If the Perl community has taught me anything it's consensus building take=
s *way* longer than 3-5 years. Moose is now 14 years old and based on the c=
onversations around Cor there is still not a full consensus about the need =
for a core object system beyond bless(), and we're just barely (say the las=
t 3-5 years) into a majority consensus that Moose is probably a reasonably =
good idea as long as you remove about 50% of it, without a real agreement o=
n which 50% should be removed.
>
> -Chris

And we don't really have any infrastructure that remotely helps
establish if there *is* any consensus. It's probably mostly a feeling
based on what you've seen in your direct peer group, interposed with
how popular it seems to be on CPAN. Sometimes I agree with others
feelings on matters. But as far as evidence goes, we'd be thrown out
of the science party.

I'm not even sure such a technology should exist, as it would surely
still exclude the voice of those who can't speak, don't wish to speak,
or weren't even told there was a place they could speak, or that there
was something happening in that place that they should speak about, or
weren't even aware there _was_ something they use which needed their
participation in order to not ruin their life.

A *meaningful* consensus is _hard_.


--=20
Kent

KENTNL - https://metacpan.org/author/KENTNL
0
kentfredric
7/2/2020 5:20:30 PM
On Thu, 2 Jul 2020 13:03:37 -0400
Chris Prather <chris@prather.org> wrote:

> If the Perl community has taught me anything it's consensus building
> takes *way* longer than 3-5 years. Moose is now 14 years old and
> based on the conversations around Cor there is still not a full
> consensus about the need for a core object system beyond bless(), and
> we're just barely (say the last 3-5 years) into a majority consensus
> that Moose is probably a reasonably good idea as long as you remove
> about 50% of it, without a real agreement on which 50% should be
> removed.

I'm not sure that's really true these days. I think most of the core
folks are relatively clear on the fact that several things are missing:

 * try/catch
 * proper exceptions to go along with theabove
 * an object and class system
 * a better thing than given/when/smartmatch

Up until now there has been much talk and very little real activity.
People sometimes come along and suggest an idea or so, but very few
concrete implementations of real code ever turn up. I know because
until quite recently I have been very guilty of this - I'll suggest
"Hey, it would be great if ..." and nobody objects, but then nothing
ever happens. You can't just suggest a feature and expect that "someone
else" will implement it.


Midway through 5.31.x I was given a commit bit, and took it upon myself
to add the `isa` feature, as I saw it was a) necessary and b) a gateway
to gaining quite a few of the above features. All of them, in fact.

It is very much my intention to keep going; through 5.33.x I hope to
address some of the above - at the very least, arriving at having a
properly stable try/catch syntax, in core, by the time a 5.34 would be
released (summertime next year). I don't think it's realistic to aim at
having the object system in by then, but provided nothing too major
ends up getting in my way, I would expect that within a year's time you
could

  use feature 'try';

  try {
    foo();
  }
  catch ($e isa My::App::Exception) {
    say "Oopsie, you did ", $e->detail;
  }
  catch ($e) {
    say "Oopsie, something went bad: $e";
  }

and maybe also

  use feature 'match';

  match(bar()->colour : eq) {
    case ("red") {
      say "It was red";
    }
    case ("green", "blue") {
      say "It was green or blue";
    }
    default {
      say "It was some other colour";
    }
  }

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/2/2020 6:38:40 PM
On Fri, 3 Jul 2020 05:20:30 +1200
Kent Fredric <kentfredric@gmail.com> wrote:

> On Fri, 3 Jul 2020 at 05:03, Chris Prather <chris@prather.org> wrote:
> >
> >
> > If the Perl community has taught me anything it's consensus
> > building takes *way* longer than 3-5 years. Moose is now 14 years
> > old and based on the conversations around Cor there is still not a
> > full consensus about the need for a core object system beyond
> > bless(), and we're just barely (say the last 3-5 years) into a
> > majority consensus that Moose is probably a reasonably good idea as
> > long as you remove about 50% of it, without a real agreement on
> > which 50% should be removed.
> >
> > -Chris  
> 
> And we don't really have any infrastructure that remotely helps
> establish if there *is* any consensus. It's probably mostly a feeling
> based on what you've seen in your direct peer group, interposed with
> how popular it seems to be on CPAN. Sometimes I agree with others
> feelings on matters. But as far as evidence goes, we'd be thrown out
> of the science party.

Yeah. I agree it is difficult.

I mostly form my ideas about what is missing from watching some of the
"pain points" in common themes of discussion in #perl on Freenode. Such
chat has lead me to feel that the main things missing are much as I
mentioned in my other message - repeated here in brief

 * try/catch
 * proper exceptions to go along with theabove
 * an object and class system
 * a better thing than given/when/smartmatch

Whereas very little noise seems to be made on the need to request
syntax features from time to time. People no more mind having to

  use feature 'say';

in order to get the say() function than they mind having to

  use List::Util 'max';

if they want the max() function. Everyone accepts - especially
programmers used to C, C++, C#, Java, ... that kind of thing - that if
you want to use functions and features in your code you often have to
request them.

And sure while it would be nice to squash out some of the long
sprawling boilerplate of many pragmata modules, I don't see anyone
wanting to reduce that to nothing - a simple "use v7;" would be just
fine for folks there. I think if we just made "use v7;" a shortcut for

  use strict;
  use warnings;
  no feature 'indirect', 'bareword-filehandles', 'multidimensional';
  etc...

That would sit just fine with justabout everyone.


At least, that's the prevailing feeling I've got from loitering in a
busy IRC chat room with around 600 active Perl users for the past
decade. Scientific? Probably not. But an interesting data point all the
same perhaps...

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/2/2020 6:53:31 PM
--000000000000646e5005a97a04e4
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 2, 2020 at 2:53 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Fri, 3 Jul 2020 05:20:30 +1200
> Kent Fredric <kentfredric@gmail.com> wrote:
>
> > On Fri, 3 Jul 2020 at 05:03, Chris Prather <chris@prather.org> wrote:
> > >
> > >
> > > If the Perl community has taught me anything it's consensus
> > > building takes *way* longer than 3-5 years. Moose is now 14 years
> > > old and based on the conversations around Cor there is still not a
> > > full consensus about the need for a core object system beyond
> > > bless(), and we're just barely (say the last 3-5 years) into a
> > > majority consensus that Moose is probably a reasonably good idea as
> > > long as you remove about 50% of it, without a real agreement on
> > > which 50% should be removed.
> > >
> > > -Chris
> >
> > And we don't really have any infrastructure that remotely helps
> > establish if there *is* any consensus. It's probably mostly a feeling
> > based on what you've seen in your direct peer group, interposed with
> > how popular it seems to be on CPAN. Sometimes I agree with others
> > feelings on matters. But as far as evidence goes, we'd be thrown out
> > of the science party.
>
> Yeah. I agree it is difficult.
>
> I mostly form my ideas about what is missing from watching some of the
> "pain points" in common themes of discussion in #perl on Freenode. Such
> chat has lead me to feel that the main things missing are much as I
> mentioned in my other message - repeated here in brief
>
>  * try/catch
>  * proper exceptions to go along with theabove
>  * an object and class system
>  * a better thing than given/when/smartmatch
>
> Whereas very little noise seems to be made on the need to request
> syntax features from time to time. People no more mind having to
>
>   use feature 'say';
>
> in order to get the say() function than they mind having to
>
>   use List::Util 'max';
>
> if they want the max() function. Everyone accepts - especially
> programmers used to C, C++, C#, Java, ... that kind of thing - that if
> you want to use functions and features in your code you often have to
> request them.
>
> And sure while it would be nice to squash out some of the long
> sprawling boilerplate of many pragmata modules, I don't see anyone
> wanting to reduce that to nothing - a simple "use v7;" would be just
> fine for folks there. I think if we just made "use v7;" a shortcut for
>
>   use strict;
>   use warnings;
>   no feature 'indirect', 'bareword-filehandles', 'multidimensional';
>   etc...
>
> That would sit just fine with justabout everyone.
>
>
> At least, that's the prevailing feeling I've got from loitering in a
> busy IRC chat room with around 600 active Perl users for the past
> decade. Scientific? Probably not. But an interesting data point all the
> same perhaps...
>

I concur with these observations, though largely from observing the same
community spaces.

-Dan

--000000000000646e5005a97a04e4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, Jul 2, 2020 at 2:53 PM Paul &quot=
;LeoNerd&quot; Evans &lt;<a href=3D"mailto:leonerd@leonerd.org.uk">leonerd@=
leonerd.org.uk</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">On Fri, 3 Jul 2020 05:20:30 +1200<=
br>
Kent Fredric &lt;<a href=3D"mailto:kentfredric@gmail.com" target=3D"_blank"=
>kentfredric@gmail.com</a>&gt; wrote:<br>
<br>
&gt; On Fri, 3 Jul 2020 at 05:03, Chris Prather &lt;<a href=3D"mailto:chris=
@prather.org" target=3D"_blank">chris@prather.org</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; If the Perl community has taught me anything it&#39;s consensus<b=
r>
&gt; &gt; building takes *way* longer than 3-5 years. Moose is now 14 years=
<br>
&gt; &gt; old and based on the conversations around Cor there is still not =
a<br>
&gt; &gt; full consensus about the need for a core object system beyond<br>
&gt; &gt; bless(), and we&#39;re just barely (say the last 3-5 years) into =
a<br>
&gt; &gt; majority consensus that Moose is probably a reasonably good idea =
as<br>
&gt; &gt; long as you remove about 50% of it, without a real agreement on<b=
r>
&gt; &gt; which 50% should be removed.<br>
&gt; &gt;<br>
&gt; &gt; -Chris=C2=A0 <br>
&gt; <br>
&gt; And we don&#39;t really have any infrastructure that remotely helps<br=
>
&gt; establish if there *is* any consensus. It&#39;s probably mostly a feel=
ing<br>
&gt; based on what you&#39;ve seen in your direct peer group, interposed wi=
th<br>
&gt; how popular it seems to be on CPAN. Sometimes I agree with others<br>
&gt; feelings on matters. But as far as evidence goes, we&#39;d be thrown o=
ut<br>
&gt; of the science party.<br>
<br>
Yeah. I agree it is difficult.<br>
<br>
I mostly form my ideas about what is missing from watching some of the<br>
&quot;pain points&quot; in common themes of discussion in #perl on Freenode=
.. Such<br>
chat has lead me to feel that the main things missing are much as I<br>
mentioned in my other message - repeated here in brief<br>
<br>
=C2=A0* try/catch<br>
=C2=A0* proper exceptions to go along with theabove<br>
=C2=A0* an object and class system<br>
=C2=A0* a better thing than given/when/smartmatch<br>
<br>
Whereas very little noise seems to be made on the need to request<br>
syntax features from time to time. People no more mind having to<br>
<br>
=C2=A0 use feature &#39;say&#39;;<br>
<br>
in order to get the say() function than they mind having to<br>
<br>
=C2=A0 use List::Util &#39;max&#39;;<br>
<br>
if they want the max() function. Everyone accepts - especially<br>
programmers used to C, C++, C#, Java, ... that kind of thing - that if<br>
you want to use functions and features in your code you often have to<br>
request them.<br>
<br>
And sure while it would be nice to squash out some of the long<br>
sprawling boilerplate of many pragmata modules, I don&#39;t see anyone<br>
wanting to reduce that to nothing - a simple &quot;use v7;&quot; would be j=
ust<br>
fine for folks there. I think if we just made &quot;use v7;&quot; a shortcu=
t for<br>
<br>
=C2=A0 use strict;<br>
=C2=A0 use warnings;<br>
=C2=A0 no feature &#39;indirect&#39;, &#39;bareword-filehandles&#39;, &#39;=
multidimensional&#39;;<br>
=C2=A0 etc...<br>
<br>
That would sit just fine with justabout everyone.<br>
<br>
<br>
At least, that&#39;s the prevailing feeling I&#39;ve got from loitering in =
a<br>
busy IRC chat room with around 600 active Perl users for the past<br>
decade. Scientific? Probably not. But an interesting data point all the<br>
same perhaps...<br></blockquote><div><br></div><div>I concur with these obs=
ervations, though largely from observing the same community spaces.</div><d=
iv><br></div><div>-Dan=C2=A0</div></div></div>

--000000000000646e5005a97a04e4--
0
grinnz
7/2/2020 6:59:41 PM
--00000000000069625d05a97a7a35
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 2, 2020 at 2:38 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Thu, 2 Jul 2020 13:03:37 -0400
> Chris Prather <chris@prather.org> wrote:
>
> > If the Perl community has taught me anything it's consensus building
> > takes *way* longer than 3-5 years. Moose is now 14 years old and
> > based on the conversations around Cor there is still not a full
> > consensus about the need for a core object system beyond bless(), and
> > we're just barely (say the last 3-5 years) into a majority consensus
> > that Moose is probably a reasonably good idea as long as you remove
> > about 50% of it, without a real agreement on which 50% should be
> > removed.
>
> I'm not sure that's really true these days. I think most of the core
> folks are relatively clear on the fact that several things are missing:
>
>  * try/catch
>  * proper exceptions to go along with theabove
>  * an object and class system
>  * a better thing than given/when/smartmatch
>
> Up until now there has been much talk and very little real activity.
> People sometimes come along and suggest an idea or so, but very few
> concrete implementations of real code ever turn up. I know because
> until quite recently I have been very guilty of this - I'll suggest
> "Hey, it would be great if ..." and nobody objects, but then nothing
> ever happens. You can't just suggest a feature and expect that "someone
> else" will implement it.
>

Kinda exactly my point. We have been working on try/catch for  at least 11
years, and your specific implementation is 4 years old, with at least one
more year of development to get it into core. By any reasonable measure
we're either right against the 5 year window, or well past double it,
before agreeing that a specific proposal should be in core. Can we
reasonably say that in 5 years we'll have a consensus on how to replace it
should it turn out to be a bad idea?

And that's a well defined problem that was fairly well understood (at least
by the core developers) before Try::Tiny dropped into the scene. To
paraphrase Dan Book from irc.perl.org/#cor the other day:

"[Features] are like Unicode. Everything thinks it means some obvious
thing, but it's difficult to get to the point where they'll explain which
of 20 things they mean if they even know"

Without a concrete proposal then consensus is effectively meaningless. And
you're exactly right that we've had a lack of concrete examples. Like you,
I myself am as much to blame as anyone. Unlike you I haven't usefully
contributed to the core yet, so take my opinion with a grain of salt.

-Chris

--00000000000069625d05a97a7a35
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, Jul 2, 2020 at 2:38 PM Paul &quot=
;LeoNerd&quot; Evans &lt;<a href=3D"mailto:leonerd@leonerd.org.uk">leonerd@=
leonerd.org.uk</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">On Thu, 2 Jul 2020 13:03:37 -0400<=
br>
Chris Prather &lt;<a href=3D"mailto:chris@prather.org" target=3D"_blank">ch=
ris@prather.org</a>&gt; wrote:<br>
<br>
&gt; If the Perl community has taught me anything it&#39;s consensus buildi=
ng<br>
&gt; takes *way* longer than 3-5 years. Moose is now 14 years old and<br>
&gt; based on the conversations around Cor there is still not a full<br>
&gt; consensus about the need for a core object system beyond bless(), and<=
br>
&gt; we&#39;re just barely (say the last 3-5 years) into a majority consens=
us<br>
&gt; that Moose is probably a reasonably good idea as long as you remove<br=
>
&gt; about 50% of it, without a real agreement on which 50% should be<br>
&gt; removed.<br>
<br>
I&#39;m not sure that&#39;s really true these days. I think most of the cor=
e<br>
folks are relatively clear on the fact that several things are missing:<br>
<br>
=C2=A0* try/catch<br>
=C2=A0* proper exceptions to go along with theabove<br>
=C2=A0* an object and class system<br>
=C2=A0* a better thing than given/when/smartmatch<br>
<br>
Up until now there has been much talk and very little real activity.<br>
People sometimes come along and suggest an idea or so, but very few<br>
concrete implementations of real code ever turn up. I know because<br>
until quite recently I have been very guilty of this - I&#39;ll suggest<br>
&quot;Hey, it would be great if ...&quot; and nobody objects, but then noth=
ing<br>
ever happens. You can&#39;t just suggest a feature and expect that &quot;so=
meone<br>
else&quot; will implement it.<br></blockquote><div><br></div><div>Kinda exa=
ctly my point. We have been working on try/catch for=C2=A0 at least 11 year=
s, and your specific implementation is 4 years old, with at least one more =
year of development to get it into core. By any reasonable measure we&#39;r=
e either right against the 5 year window, or well past double it, before ag=
reeing that a specific proposal should be in core. Can we reasonably say th=
at in 5 years we&#39;ll have a consensus on how to replace it should it tur=
n out to be a bad idea? <br></div><div><br></div><div>And that&#39;s a well=
 defined problem that was fairly well understood (at least by the core deve=
lopers) before Try::Tiny dropped into the scene. To paraphrase Dan Book fro=
m <a href=3D"http://irc.perl.org/#cor">irc.perl.org/#cor</a> the other day:=
</div><div><br></div><div>&quot;[Features] are like Unicode. Everything thi=
nks it means some obvious thing, but it&#39;s difficult to get to the point=
 where they&#39;ll explain which of 20 things they mean if they even know&q=
uot;</div><div><br></div>Without a concrete proposal then consensus is effe=
ctively meaningless. And you&#39;re exactly right that we&#39;ve had a lack=
 of concrete examples. Like you, I myself am as much to blame as anyone. Un=
like you I haven&#39;t usefully contributed to the core yet, so take my opi=
nion with a grain of salt.<br></div><div class=3D"gmail_quote"><br></div><d=
iv class=3D"gmail_quote">-Chris<br></div><div class=3D"gmail_quote"><div><b=
r> </div></div></div>

--00000000000069625d05a97a7a35--
0
chris
7/2/2020 7:32:57 PM
On 2020-07-02 10:03 a.m., Chris Prather wrote:
> If the Perl community has taught me anything it's consensus building takes *way* 
> longer than 3-5 years. Moose is now 14 years old and based on the conversations 
> around Cor there is still not a full consensus about the need for a core object 
> system beyond bless(), and we're just barely (say the last 3-5 years) into a 
> majority consensus that Moose is probably a reasonably good idea as long as you 
> remove about 50% of it, without a real agreement on which 50% should be removed.

 From what I've seen, the majority wants a more sophisticated core object system 
to exist and its mainly just a fringe that insists it must come from frameworks 
because that's the Perl way and putting one in core is oppression by the man.

The only serious debate I see is just about what form the new core object system 
should take and how fast it should be committed to.  Its working out the details 
and the timetable that is the issue, and getting close enough to a consensus on 
that (a complete consensus would never happen).

-- Darren Duncan
0
darren
7/3/2020 1:38:39 AM
--0000000000000d0c7805a99ae8b0
Content-Type: text/plain; charset="UTF-8"

On Thu, 2 Jul 2020 at 20:38, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Thu, 2 Jul 2020 13:03:37 -0400
> Chris Prather <chris@prather.org> wrote:
>
> > If the Perl community has taught me anything it's consensus building
> > takes *way* longer than 3-5 years. Moose is now 14 years old and
> > based on the conversations around Cor there is still not a full
> > consensus about the need for a core object system beyond bless(), and
> > we're just barely (say the last 3-5 years) into a majority consensus
> > that Moose is probably a reasonably good idea as long as you remove
> > about 50% of it, without a real agreement on which 50% should be
> > removed.
>
> I'm not sure that's really true these days. I think most of the core
> folks are relatively clear on the fact that several things are missing:
>
>  * try/catch
>  * proper exceptions to go along with theabove
>  * an object and class system
>  * a better thing than given/when/smartmatch
>
> Up until now there has been much talk and very little real activity.
> People sometimes come along and suggest an idea or so, but very few
> concrete implementations of real code ever turn up. I know because
> until quite recently I have been very guilty of this - I'll suggest
> "Hey, it would be great if ..." and nobody objects, but then nothing
> ever happens. You can't just suggest a feature and expect that "someone
> else" will implement it.
>
>
> Midway through 5.31.x I was given a commit bit, and took it upon myself
> to add the `isa` feature, as I saw it was a) necessary and b) a gateway
> to gaining quite a few of the above features. All of them, in fact.
>
> It is very much my intention to keep going; through 5.33.x I hope to
> address some of the above - at the very least, arriving at having a
> properly stable try/catch syntax, in core, by the time a 5.34 would be
> released (summertime next year). I don't think it's realistic to aim at
> having the object system in by then, but provided nothing too major
> ends up getting in my way, I would expect that within a year's time you
> could
>
>   use feature 'try';
>
>   try {
>     foo();
>   }
>   catch ($e isa My::App::Exception) {
>

To be honest, as long as there are roles, usage of isa is not clean yet.
- similar java operator instanceof behaves the same for classes and
interfaces, why not here?
- how to catch $e with a parameterized role?
- how to resolve multiple inheritance ?
- in what order catches will be executed?

imagine:
exception X;
exception X::Y extends X;
catch ($e isa X) { ... }
catch ($e isa X::Y) { ... }

And this concerns only simple OOP matching.

I'd suggest delivering this feature in multiple steps:
1. lexical CATCH { BLOCK }
- will be consistent with your other plan - lexical LEAVE
- will add good enough value on its own
- still maintain try module but using this feature

2a. design data pattern language
there is a long discussion (and none usable result) about it since smart
match operator was introduced.
IMHO this should include first class class literals as well.

2b. CATCH should handle any kind of asynchronous events, including
- signals
- warnings
- core events (eg: there is a thread to join)
- custom asynchronous events (eg: file has data to read, file can be
written to, HTTP request succeeded, ...)

3. extend lexical CATCH using data pattern language
- issue to solve: evaluation priority in case exception matches multiple
patterns along with  unreachable code detection



>     say "Oopsie, you did ", $e->detail;
>   }
>   catch ($e) {
>     say "Oopsie, something went bad: $e";
>   }
>
> and maybe also
>
>   use feature 'match';
>
>   match(bar()->colour : eq) {
>     case ("red") {
>       say "It was red";
>     }
>     case ("green", "blue") {
>       say "It was green or blue";
>     }
>     default {
>       say "It was some other colour";
>     }
>   }
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
>

--0000000000000d0c7805a99ae8b0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 2 Jul 2020 a=
t 20:38, Paul &quot;LeoNerd&quot; Evans &lt;<a href=3D"mailto:leonerd@leone=
rd.org.uk">leonerd@leonerd.org.uk</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">On Thu, 2 Jul 2020 13:03:37 -0400<br>
Chris Prather &lt;<a href=3D"mailto:chris@prather.org" target=3D"_blank">ch=
ris@prather.org</a>&gt; wrote:<br>
<br>
&gt; If the Perl community has taught me anything it&#39;s consensus buildi=
ng<br>
&gt; takes *way* longer than 3-5 years. Moose is now 14 years old and<br>
&gt; based on the conversations around Cor there is still not a full<br>
&gt; consensus about the need for a core object system beyond bless(), and<=
br>
&gt; we&#39;re just barely (say the last 3-5 years) into a majority consens=
us<br>
&gt; that Moose is probably a reasonably good idea as long as you remove<br=
>
&gt; about 50% of it, without a real agreement on which 50% should be<br>
&gt; removed.<br>
<br>
I&#39;m not sure that&#39;s really true these days. I think most of the cor=
e<br>
folks are relatively clear on the fact that several things are missing:<br>
<br>
=C2=A0* try/catch<br>
=C2=A0* proper exceptions to go along with theabove<br>
=C2=A0* an object and class system<br>
=C2=A0* a better thing than given/when/smartmatch<br>
<br>
Up until now there has been much talk and very little real activity.<br>
People sometimes come along and suggest an idea or so, but very few<br>
concrete implementations of real code ever turn up. I know because<br>
until quite recently I have been very guilty of this - I&#39;ll suggest<br>
&quot;Hey, it would be great if ...&quot; and nobody objects, but then noth=
ing<br>
ever happens. You can&#39;t just suggest a feature and expect that &quot;so=
meone<br>
else&quot; will implement it.<br>
<br>
<br>
Midway through 5.31.x I was given a commit bit, and took it upon myself<br>
to add the `isa` feature, as I saw it was a) necessary and b) a gateway<br>
to gaining quite a few of the above features. All of them, in fact.<br>
<br>
It is very much my intention to keep going; through 5.33.x I hope to<br>
address some of the above - at the very least, arriving at having a<br>
properly stable try/catch syntax, in core, by the time a 5.34 would be<br>
released (summertime next year). I don&#39;t think it&#39;s realistic to ai=
m at<br>
having the object system in by then, but provided nothing too major<br>
ends up getting in my way, I would expect that within a year&#39;s time you=
<br>
could<br>
<br>
=C2=A0 use feature &#39;try&#39;;<br>
<br>
=C2=A0 try {<br>
=C2=A0 =C2=A0 foo();<br>
=C2=A0 }<br>
=C2=A0 catch ($e isa My::App::Exception) {<br></blockquote><div><br></div><=
div>To be honest, as long as there are roles, usage of isa is not clean yet=
..</div><div>- similar java operator instanceof behaves the same for classes=
 and interfaces, why not here?</div><div></div><div>- how to catch $e with =
a parameterized role?</div><div></div><div>- how to resolve multiple inheri=
tance ?</div><div>- in what order catches will be executed?</div><div><br><=
/div><div>imagine:</div><div>exception X;</div><div>exception X::Y extends =
X;</div><div>catch ($e isa X) { ... }</div><div>catch ($e isa X::Y) { ... }=
<br></div><div><br></div><div>And this concerns only simple OOP matching.</=
div><div><br></div><div>I&#39;d suggest delivering this feature in multiple=
 steps:</div><div>1. lexical CATCH { BLOCK }<br></div><div>- will be consis=
tent with your other plan - lexical LEAVE</div><div>- will add good enough =
value on its own</div><div>- still maintain try module but using this featu=
re</div><div><br></div><div>2a. design data pattern language</div><div>ther=
e is a long discussion (and none usable result) about it since smart match =
operator was introduced.</div><div>IMHO this should include first class cla=
ss literals as well.</div><div></div><div><br></div><div>2b. CATCH should h=
andle any kind of asynchronous events, including</div><div>- signals</div><=
div>- warnings</div><div>- core events (eg: there is a thread to join)</div=
><div>- custom asynchronous events (eg: file has data to read, file can be =
written to, HTTP request succeeded, ...)<br></div><div><br></div><div>3. ex=
tend lexical CATCH using data pattern language</div><div>- issue to solve: =
evaluation priority in case exception matches multiple patterns along with=
=C2=A0 unreachable code detection</div><div><br></div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">
=C2=A0 =C2=A0 say &quot;Oopsie, you did &quot;, $e-&gt;detail;<br>
=C2=A0 }<br>
=C2=A0 catch ($e) {<br>
=C2=A0 =C2=A0 say &quot;Oopsie, something went bad: $e&quot;;<br>
=C2=A0 }<br>
<br>
and maybe also<br>
<br>
=C2=A0 use feature &#39;match&#39;;<br>
<br>
=C2=A0 match(bar()-&gt;colour : eq) {<br>
=C2=A0 =C2=A0 case (&quot;red&quot;) {<br>
=C2=A0 =C2=A0 =C2=A0 say &quot;It was red&quot;;<br>
=C2=A0 =C2=A0 }<br>
=C2=A0 =C2=A0 case (&quot;green&quot;, &quot;blue&quot;) {<br>
=C2=A0 =C2=A0 =C2=A0 say &quot;It was green or blue&quot;;<br>
=C2=A0 =C2=A0 }<br>
=C2=A0 =C2=A0 default {<br>
=C2=A0 =C2=A0 =C2=A0 say &quot;It was some other colour&quot;;<br>
=C2=A0 =C2=A0 }<br>
=C2=A0 }<br>
<br>
-- <br>
Paul &quot;LeoNerd&quot; Evans<br>
<br>
<a href=3D"mailto:leonerd@leonerd.org.uk" target=3D"_blank">leonerd@leonerd=
..org.uk</a>=C2=A0 =C2=A0 =C2=A0 |=C2=A0 <a href=3D"https://metacpan.org/aut=
hor/PEVANS" rel=3D"noreferrer" target=3D"_blank">https://metacpan.org/autho=
r/PEVANS</a><br>
<a href=3D"http://www.leonerd.org.uk/" rel=3D"noreferrer" target=3D"_blank"=
>http://www.leonerd.org.uk/</a>=C2=A0 |=C2=A0 <a href=3D"https://www.tindie=
..com/stores/leonerd/" rel=3D"noreferrer" target=3D"_blank">https://www.tind=
ie.com/stores/leonerd/</a><br>
</blockquote></div></div></div>

--0000000000000d0c7805a99ae8b0--
0
happy
7/4/2020 10:14:15 AM
On Sat, 4 Jul 2020 12:14:15 +0200
Branislav Zahradn=C3=ADk <happy.barney@gmail.com> wrote:

> >   use feature 'try';
> >
> >   try {
> >     foo();
> >   }
> >   catch ($e isa My::App::Exception) {
> > =20
>=20
> To be honest, as long as there are roles, usage of isa is not clean
> yet.
> - similar java operator instanceof behaves the same for classes and
> interfaces, why not here?

One reason the `isa` is still experimental (other than being so new) is
that there still needs to be a corresponding `does` operator to perform
the role check via the ->DOES method.

> - how to catch $e with a parameterized role?

There isn't the concept of a parameterized role anywhere else in Perl
currently, so this isn't a question that is meaningful.

> - how to resolve multiple inheritance ?
> - in what order catches will be executed?
>=20
> imagine:
> exception X;
> exception X::Y extends X;
> catch ($e isa X) { ... }
> catch ($e isa X::Y) { ... }
>=20
> And this concerns only simple OOP matching.

Multiple catch blocks, as for dumbmatch, simply perform their tests in
lexical order. If you want a particular case to take precedence over
another case, move it higher up in the source code. This is by far the
simplest to implement, to understand, and to explain to users.

It also makes it feel similar to the test order in the traditional
if/elsif/.../else style of code.

> I'd suggest delivering this feature in multiple steps:
> 1. lexical CATCH { BLOCK }
> - will be consistent with your other plan - lexical LEAVE
> - will add good enough value on its own
> - still maintain try module but using this feature

I still majorly dislike the idea of a `CATCH` block, because its mere
presence inside the parent block changes the semantics of that block,
even at lines before it appears. This isn't the case with `LEAVE` or
any of the other existing phaser blocks in perl; which only observe at
a particular moment in time but do not otherwise alter it.

Restated: `LEAVE` is fine as a passive observer simply sitting as a
sibling block to other code. But the interruption of control flow
implied by `catch`-like behaviour is sufficiently surprising that it's
good to warn the (human) reader of the code by the presence of the
`try` block to contain it. The `try` part of `try/catch` syntax exists
primarily for the benefit of the human programmer, not the perl
interpreter.

--=20
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/4/2020 11:27:12 AM
--0000000000004d904a05a99c471a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 4 Jul 2020 at 13:27, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Sat, 4 Jul 2020 12:14:15 +0200
> Branislav Zahradn=C3=ADk <happy.barney@gmail.com> wrote:
>
>
> `try` block to contain it. The `try` part of `try/catch` syntax exists
> primarily for the benefit of the human programmer, not the perl
> interpreter.
>

This way you are still handling only exceptions ignoring other asynchronous
events.

ad benefit of the human, here I will disagree.
I modified some java code to show an example:

Original method with try/catch:
https://pastebin.com/eSV5AgRd

Modified with  lexical catch:
https://pastebin.com/kHWjTs2r

As a human reader it's easier for me to be notified about possible exit
before exit happens.
(Imagine GPS navigation talking like try/catch block: "200 meters ago you
had to turn left")




> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
>

--0000000000004d904a05a99c471a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sat, 4 Jul 2020 at 13:27, Paul &qu=
ot;LeoNerd&quot; Evans &lt;<a href=3D"mailto:leonerd@leonerd.org.uk">leoner=
d@leonerd.org.uk</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">On Sat, 4 Jul 2020 12:14:15 +0200<br>
Branislav Zahradn=C3=ADk &lt;<a href=3D"mailto:happy.barney@gmail.com" targ=
et=3D"_blank">happy.barney@gmail.com</a>&gt; wrote:<br>
<br><br>
`try` block to contain it. The `try` part of `try/catch` syntax exists<br>
primarily for the benefit of the human programmer, not the perl<br>
interpreter.<br></blockquote><div><br></div><div>This way you are still han=
dling only exceptions ignoring other asynchronous events.</div><div><br></d=
iv><div>ad benefit of the human, here I will disagree.</div><div>I modified=
 some java code to show an example:</div><div><br></div><div>Original metho=
d with try/catch:</div><div><a href=3D"https://pastebin.com/eSV5AgRd">https=
://pastebin.com/eSV5AgRd</a></div><div><br></div><div>Modified with=C2=A0 l=
exical catch:</div><div><a href=3D"https://pastebin.com/kHWjTs2r">https://p=
astebin.com/kHWjTs2r</a></div><div><br></div><div>As a human reader it&#39;=
s easier for me to be notified about possible exit before exit happens.</di=
v><div>(Imagine GPS navigation talking like try/catch block: &quot;200 mete=
rs ago you had to turn left&quot;)<br></div><div><br></div><div>=C2=A0</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
Paul &quot;LeoNerd&quot; Evans<br>
<br>
<a href=3D"mailto:leonerd@leonerd.org.uk" target=3D"_blank">leonerd@leonerd=
..org.uk</a>=C2=A0 =C2=A0 =C2=A0 |=C2=A0 <a href=3D"https://metacpan.org/aut=
hor/PEVANS" rel=3D"noreferrer" target=3D"_blank">https://metacpan.org/autho=
r/PEVANS</a><br>
<a href=3D"http://www.leonerd.org.uk/" rel=3D"noreferrer" target=3D"_blank"=
>http://www.leonerd.org.uk/</a>=C2=A0 |=C2=A0 <a href=3D"https://www.tindie=
..com/stores/leonerd/" rel=3D"noreferrer" target=3D"_blank">https://www.tind=
ie.com/stores/leonerd/</a><br>
</blockquote></div></div>

--0000000000004d904a05a99c471a--
0
happy
7/4/2020 11:52:28 AM
Reply: