Mailing List Archive

On 6/11/22 02:37, Neil Bowers wrote:
> > Can someone show an example, ideally on CPAN, where this gets used?
>
> I _think_ you were asking for an example of someone using the return
> value from a require. In which case:
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm
> <https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm>
>
> This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):
>
>     if ( $] >= 5.006 && $] < 5.007003  ) {
>         eval { $data = require 'unicode/Name.pl'; };
>     }
>     elsif ( $] >= 5.007003 ) {
>         eval { $data = require 'unicore/Name.pl'; };
>
>         # since v5.11.3, unicore/Name.pl creates subroutines
>         # they end up in our namespace, so get rid of them
>         undef *code_point_to_name_special;
>         undef *name_to_code_point_special;
>     }

I feel compelled to point out that the file read-in in this example,
unicore/Name.pl, has the following text at its top

# !!!!!!! INTERNAL PERL USE ONLY !!!!!!!
# This file is for internal use by core Perl only. The format and even the
# name or existence of this file are subject to change without notice.
Don't
# use it directly. Use Unicode::UCD to access the Unicode character data
# base.


top of says:

2022-6-11 3:22 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

>
> 3. The surrounding `require` would ignore *any* return value (whether
> implicit because of EOF, or explicit from `return`), and behave as
> if `true` had been returned
>
> Therefore I think we should go with option 3; which would involve
> altering the implementation of `require` to just ignore the return
> value of the loaded file if `feature 'yield_true'` was in effect by the
> time it reached EOF and hadn't already thrown an exception by that time.
>
>
A problem of 3 is that a new module which has no "1;" at the end can't be
loaded from old codes.

I think 3 is good, however a little adjustment is needed.

2022-6-13 11:02 Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

>
>
> 2022-6-11 3:22 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
>
>>
>> 3. The surrounding `require` would ignore *any* return value (whether
>> implicit because of EOF, or explicit from `return`), and behave as
>> if `true` had been returned
>>
>> Therefore I think we should go with option 3; which would involve
>> altering the implementation of `require` to just ignore the return
>> value of the loaded file if `feature 'yield_true'` was in effect by the
>> time it reached EOF and hadn't already thrown an exception by that time.
>>
>>
> A problem of 3 is that a new module which has no "1;" at the end can't be
> loaded from old codes.
>
> I think 3 is good, however a little adjustment is needed.
>

> Therefore I think we should go with option 3; which would involve
altering the implementation of `require` to just ignore the return
value of the loaded file if `feature 'yield_true'` was in effect by the
time it reached EOF and hadn't already thrown an exception by that time.

I think this seems to be the 4th choice from the perspective of both
changing "require" and implementing "yield_true" feature.

On Mon, Jun 13, 2022 at 4:02 AM Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

>
>
> 2022-6-11 3:22 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
>
>>
>> 3. The surrounding `require` would ignore *any* return value (whether
>> implicit because of EOF, or explicit from `return`), and behave as
>> if `true` had been returned
>>
>> Therefore I think we should go with option 3; which would involve
>> altering the implementation of `require` to just ignore the return
>> value of the loaded file if `feature 'yield_true'` was in effect by the
>> time it reached EOF and hadn't already thrown an exception by that time.
>>
>>
> A problem of 3 is that a new module which has no "1;" at the end can't be
> loaded from old codes.
>
> I think 3 is good, however a little adjustment is needed.
>

As a module using this feature would require v5.38 this is a non-problem.

On Sat, Jun 11, 2022 at 10:37 AM Neil Bowers <neilb@neilb.org> wrote:

> > Can someone show an example, ideally on CPAN, where this gets used?
>
> I _think_ you were asking for an example of someone using the return value
> from a require. In which case:
>
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm
>
> This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):
>
> if ( $] >= 5.006 && $] < 5.007003 ) {
> eval { $data = require 'unicode/Name.pl'; };
> }
> elsif ( $] >= 5.007003 ) {
> eval { $data = require 'unicore/Name.pl'; };
>
> # since v5.11.3, unicore/Name.pl creates subroutines
> # they end up in our namespace, so get rid of them
> undef *code_point_to_name_special;
> undef *name_to_code_point_special;
> }
>
> Guessing there may be other examples on CPAN – this is just the first one
> I found with grep.metacpan.org.
>
> Neil
>
>

Thanks for the grep.metacpan.org link, haven't thought about it for finding
examples. I've looked at some others and using the return value of a
require call is used quite frequently. So option 3 isn't a good one in my
opinion, as a module changed to use the feature, most probably with 'use
v5.38;' not thinking about the enabled feature, which would lead to another
module failing because of the changed behavior.

On Mon, Jun 13, 2022 at 12:21 PM Alexander Hartmaier
<alex.hartmaier@gmail.com> wrote:
>
> On Sat, Jun 11, 2022 at 10:37 AM Neil Bowers <neilb@neilb.org> wrote:
>>
>> > Can someone show an example, ideally on CPAN, where this gets used?
>>
>> I _think_ you were asking for an example of someone using the return value from a require. In which case:
>>
>> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm
>>
>> This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):
>>
>> if ( $] >= 5.006 && $] < 5.007003 ) {
>> eval { $data = require 'unicode/Name.pl'; };
>> }
>> elsif ( $] >= 5.007003 ) {
>> eval { $data = require 'unicore/Name.pl'; };
>>
>> # since v5.11.3, unicore/Name.pl creates subroutines
>> # they end up in our namespace, so get rid of them
>> undef *code_point_to_name_special;
>> undef *name_to_code_point_special;
>> }
>>
>> Guessing there may be other examples on CPAN – this is just the first one I found with grep.metacpan.org.
>>
>> Neil
>>
>
>
> Thanks for the grep.metacpan.org link, haven't thought about it for finding examples. I've looked at some others and using the return value of a require call is used quite frequently. So option 3 isn't a good one in my opinion, as a module changed to use the feature, most probably with 'use v5.38;' not thinking about the enabled feature, which would lead to another module failing because of the changed behavior.

Anything relying on the return value of require as being anything
other than true is already broken. The second time require is called
for a module, it will turn true, not whatever the module tried to
return. unicode/Name.pl is meant to be loaded via do, not require, in
addition to being internal only.

Going back to perl 5.30, the last version Acme::MetaSyntactic passed
its tests on, it still fails if you cause Name.pl to be loaded early.

$ perl -e'use strict; use warnings; use charnames qw(greek); use
Acme::MetaSyntactic; my $meta = Acme::MetaSyntactic->new("unicode");
die "no names!" if !$meta->name;'
no names! at -e line 1.

I'd say it's better to cause these things to always fail, rather than
allowing them to sometimes appear to work.

On Mon, Jun 13, 2022 at 12:43 PM Graham Knop <haarg@haarg.org> wrote:

> On Mon, Jun 13, 2022 at 12:21 PM Alexander Hartmaier
> <alex.hartmaier@gmail.com> wrote:
> >
> > On Sat, Jun 11, 2022 at 10:37 AM Neil Bowers <neilb@neilb.org> wrote:
> >>
> >> > Can someone show an example, ideally on CPAN, where this gets used?
> >>
> >> I _think_ you were asking for an example of someone using the return
> value from a require. In which case:
> >>
> >>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm
> >>
> >> This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):
> >>
> >> if ( $] >= 5.006 && $] < 5.007003 ) {
> >> eval { $data = require 'unicode/Name.pl'; };
> >> }
> >> elsif ( $] >= 5.007003 ) {
> >> eval { $data = require 'unicore/Name.pl'; };
> >>
> >> # since v5.11.3, unicore/Name.pl creates subroutines
> >> # they end up in our namespace, so get rid of them
> >> undef *code_point_to_name_special;
> >> undef *name_to_code_point_special;
> >> }
> >>
> >> Guessing there may be other examples on CPAN – this is just the first
> one I found with grep.metacpan.org.
> >>
> >> Neil
> >>
> >
> >
> > Thanks for the grep.metacpan.org link, haven't thought about it for
> finding examples. I've looked at some others and using the return value of
> a require call is used quite frequently. So option 3 isn't a good one in my
> opinion, as a module changed to use the feature, most probably with 'use
> v5.38;' not thinking about the enabled feature, which would lead to another
> module failing because of the changed behavior.
>
> Anything relying on the return value of require as being anything
> other than true is already broken. The second time require is called
> for a module, it will turn true, not whatever the module tried to
> return. unicode/Name.pl is meant to be loaded via do, not require, in
> addition to being internal only.
>
> Going back to perl 5.30, the last version Acme::MetaSyntactic passed
> its tests on, it still fails if you cause Name.pl to be loaded early.
>
> $ perl -e'use strict; use warnings; use charnames qw(greek); use
> Acme::MetaSyntactic; my $meta = Acme::MetaSyntactic->new("unicode");
> die "no names!" if !$meta->name;'
> no names! at -e line 1.
>
> I'd say it's better to cause these things to always fail, rather than
> allowing them to sometimes appear to work.
>

Look at some of the other modules using the return value of require from
the grep.metacpan.org link.

2022-6-13 18:37 Alexander Hartmaier <alex.hartmaier@gmail.com> wrote:

> On Mon, Jun 13, 2022 at 4:02 AM Yuki Kimoto <kimoto.yuki@gmail.com> wrote:
>
>>
>>
>> 2022-6-11 3:22 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
>>
>>>
>>> 3. The surrounding `require` would ignore *any* return value (whether
>>> implicit because of EOF, or explicit from `return`), and behave as
>>> if `true` had been returned
>>>
>>> Therefore I think we should go with option 3; which would involve
>>> altering the implementation of `require` to just ignore the return
>>> value of the loaded file if `feature 'yield_true'` was in effect by the
>>> time it reached EOF and hadn't already thrown an exception by that time.
>>>
>>>
>> A problem of 3 is that a new module which has no "1;" at the end can't be
>> loaded from old codes.
>>
>> I think 3 is good, however a little adjustment is needed.
>>
>
> As a module using this feature would require v5.38 this is a non-problem.
>

That is true. It was my misunderstanding.

On Tue, Jun 14, 2022 at 8:15 AM Alexander Hartmaier
<alex.hartmaier@gmail.com> wrote:
>
> On Mon, Jun 13, 2022 at 12:43 PM Graham Knop <haarg@haarg.org> wrote:
>>
>> On Mon, Jun 13, 2022 at 12:21 PM Alexander Hartmaier
>> <alex.hartmaier@gmail.com> wrote:
>> >
>> > On Sat, Jun 11, 2022 at 10:37 AM Neil Bowers <neilb@neilb.org> wrote:
>> >>
>> >> > Can someone show an example, ideally on CPAN, where this gets used?
>> >>
>> >> I _think_ you were asking for an example of someone using the return value from a require. In which case:
>> >>
>> >> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm
>> >>
>> >> This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):
>> >>
>> >> if ( $] >= 5.006 && $] < 5.007003 ) {
>> >> eval { $data = require 'unicode/Name.pl'; };
>> >> }
>> >> elsif ( $] >= 5.007003 ) {
>> >> eval { $data = require 'unicore/Name.pl'; };
>> >>
>> >> # since v5.11.3, unicore/Name.pl creates subroutines
>> >> # they end up in our namespace, so get rid of them
>> >> undef *code_point_to_name_special;
>> >> undef *name_to_code_point_special;
>> >> }
>> >>
>> >> Guessing there may be other examples on CPAN – this is just the first one I found with grep.metacpan.org.
>> >>
>> >> Neil
>> >>
>> >
>> >
>> > Thanks for the grep.metacpan.org link, haven't thought about it for finding examples. I've looked at some others and using the return value of a require call is used quite frequently. So option 3 isn't a good one in my opinion, as a module changed to use the feature, most probably with 'use v5.38;' not thinking about the enabled feature, which would lead to another module failing because of the changed behavior.
>>
>> Anything relying on the return value of require as being anything
>> other than true is already broken. The second time require is called
>> for a module, it will turn true, not whatever the module tried to
>> return. unicode/Name.pl is meant to be loaded via do, not require, in
>> addition to being internal only.
>>
>> Going back to perl 5.30, the last version Acme::MetaSyntactic passed
>> its tests on, it still fails if you cause Name.pl to be loaded early.
>>
>> $ perl -e'use strict; use warnings; use charnames qw(greek); use
>> Acme::MetaSyntactic; my $meta = Acme::MetaSyntactic->new("unicode");
>> die "no names!" if !$meta->name;'
>> no names! at -e line 1.
>>
>> I'd say it's better to cause these things to always fail, rather than
>> allowing them to sometimes appear to work.
>
>
> Look at some of the other modules using the return value of require from the grep.metacpan.org link.

Do you have a concrete example?

For most cases I saw, changing the module or file to always return
true (as in !!1) would either not make any difference, or would cause
immediate, obvious, breakage. Either of which is fine.

On Tue, Jun 14, 2022 at 11:33 AM Graham Knop <haarg@haarg.org> wrote:

> On Tue, Jun 14, 2022 at 8:15 AM Alexander Hartmaier
> <alex.hartmaier@gmail.com> wrote:
> >
> > On Mon, Jun 13, 2022 at 12:43 PM Graham Knop <haarg@haarg.org> wrote:
> >>
> >> On Mon, Jun 13, 2022 at 12:21 PM Alexander Hartmaier
> >> <alex.hartmaier@gmail.com> wrote:
> >> >
> >> > On Sat, Jun 11, 2022 at 10:37 AM Neil Bowers <neilb@neilb.org> wrote:
> >> >>
> >> >> > Can someone show an example, ideally on CPAN, where this gets used?
> >> >>
> >> >> I _think_ you were asking for an example of someone using the return
> value from a require. In which case:
> >> >>
> >> >>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm
> >> >>
> >> >> This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):
> >> >>
> >> >> if ( $] >= 5.006 && $] < 5.007003 ) {
> >> >> eval { $data = require 'unicode/Name.pl'; };
> >> >> }
> >> >> elsif ( $] >= 5.007003 ) {
> >> >> eval { $data = require 'unicore/Name.pl'; };
> >> >>
> >> >> # since v5.11.3, unicore/Name.pl creates subroutines
> >> >> # they end up in our namespace, so get rid of them
> >> >> undef *code_point_to_name_special;
> >> >> undef *name_to_code_point_special;
> >> >> }
> >> >>
> >> >> Guessing there may be other examples on CPAN – this is just the
> first one I found with grep.metacpan.org.
> >> >>
> >> >> Neil
> >> >>
> >> >
> >> >
> >> > Thanks for the grep.metacpan.org link, haven't thought about it for
> finding examples. I've looked at some others and using the return value of
> a require call is used quite frequently. So option 3 isn't a good one in my
> opinion, as a module changed to use the feature, most probably with 'use
> v5.38;' not thinking about the enabled feature, which would lead to another
> module failing because of the changed behavior.
> >>
> >> Anything relying on the return value of require as being anything
> >> other than true is already broken. The second time require is called
> >> for a module, it will turn true, not whatever the module tried to
> >> return. unicode/Name.pl is meant to be loaded via do, not require, in
> >> addition to being internal only.
> >>
> >> Going back to perl 5.30, the last version Acme::MetaSyntactic passed
> >> its tests on, it still fails if you cause Name.pl to be loaded early.
> >>
> >> $ perl -e'use strict; use warnings; use charnames qw(greek); use
> >> Acme::MetaSyntactic; my $meta = Acme::MetaSyntactic->new("unicode");
> >> die "no names!" if !$meta->name;'
> >> no names! at -e line 1.
> >>
> >> I'd say it's better to cause these things to always fail, rather than
> >> allowing them to sometimes appear to work.
> >
> >
> > Look at some of the other modules using the return value of require from
> the grep.metacpan.org link.
>
> Do you have a concrete example?
>
> I've just removed the dist filter from Neils query, added *.pm to get rid
of the dist.ini matches and looked at some modules:
https://grep.metacpan.org/search?q=%3D+require&qd=&qft=*.pm

For example https://metacpan.org/dist/DT/source/lib/DT.pm#L49 and
https://metacpan.org/dist/File-FindLib/source/FindLib.pm#L55 are examples
I'd pick as reference.


> For most cases I saw, changing the module or file to always return
> true (as in !!1) would either not make any difference, or would cause
> immediate, obvious, breakage. Either of which is fine.
>

On Tue, Jun 14, 2022 at 6:02 PM Alexander Hartmaier
<alex.hartmaier@gmail.com> wrote:
>
> On Tue, Jun 14, 2022 at 11:33 AM Graham Knop <haarg@haarg.org> wrote:
>>
>> On Tue, Jun 14, 2022 at 8:15 AM Alexander Hartmaier
>> <alex.hartmaier@gmail.com> wrote:
>> >
>> > On Mon, Jun 13, 2022 at 12:43 PM Graham Knop <haarg@haarg.org> wrote:
>> >>
>> >> On Mon, Jun 13, 2022 at 12:21 PM Alexander Hartmaier
>> >> <alex.hartmaier@gmail.com> wrote:
>> >> >
>> >> > On Sat, Jun 11, 2022 at 10:37 AM Neil Bowers <neilb@neilb.org> wrote:
>> >> >>
>> >> >> > Can someone show an example, ideally on CPAN, where this gets used?
>> >> >>
>> >> >> I _think_ you were asking for an example of someone using the return value from a require. In which case:
>> >> >>
>> >> >> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm
>> >> >>
>> >> >> This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):
>> >> >>
>> >> >> if ( $] >= 5.006 && $] < 5.007003 ) {
>> >> >> eval { $data = require 'unicode/Name.pl'; };
>> >> >> }
>> >> >> elsif ( $] >= 5.007003 ) {
>> >> >> eval { $data = require 'unicore/Name.pl'; };
>> >> >>
>> >> >> # since v5.11.3, unicore/Name.pl creates subroutines
>> >> >> # they end up in our namespace, so get rid of them
>> >> >> undef *code_point_to_name_special;
>> >> >> undef *name_to_code_point_special;
>> >> >> }
>> >> >>
>> >> >> Guessing there may be other examples on CPAN – this is just the first one I found with grep.metacpan.org.
>> >> >>
>> >> >> Neil
>> >> >>
>> >> >
>> >> >
>> >> > Thanks for the grep.metacpan.org link, haven't thought about it for finding examples. I've looked at some others and using the return value of a require call is used quite frequently. So option 3 isn't a good one in my opinion, as a module changed to use the feature, most probably with 'use v5.38;' not thinking about the enabled feature, which would lead to another module failing because of the changed behavior.
>> >>
>> >> Anything relying on the return value of require as being anything
>> >> other than true is already broken. The second time require is called
>> >> for a module, it will turn true, not whatever the module tried to
>> >> return. unicode/Name.pl is meant to be loaded via do, not require, in
>> >> addition to being internal only.
>> >>
>> >> Going back to perl 5.30, the last version Acme::MetaSyntactic passed
>> >> its tests on, it still fails if you cause Name.pl to be loaded early.
>> >>
>> >> $ perl -e'use strict; use warnings; use charnames qw(greek); use
>> >> Acme::MetaSyntactic; my $meta = Acme::MetaSyntactic->new("unicode");
>> >> die "no names!" if !$meta->name;'
>> >> no names! at -e line 1.
>> >>
>> >> I'd say it's better to cause these things to always fail, rather than
>> >> allowing them to sometimes appear to work.
>> >
>> >
>> > Look at some of the other modules using the return value of require from the grep.metacpan.org link.
>>
>> Do you have a concrete example?
>>
> I've just removed the dist filter from Neils query, added *.pm to get rid of the dist.ini matches and looked at some modules: https://grep.metacpan.org/search?q=%3D+require&qd=&qft=*.pm
>
> For example https://metacpan.org/dist/DT/source/lib/DT.pm#L49

This only cares that require returns a true value, and avoids calling
return again in the future if so.

> and https://metacpan.org/dist/File-FindLib/source/FindLib.pm#L55 are examples I'd pick as reference.

This just passes the value on, doing nothing with it. There are no
users of File::FindLib on CPAN that use that return value.

Neither of these would be impacted by changing the return value to be
a simple true value.

>
>>
>> For most cases I saw, changing the module or file to always return
>> true (as in !!1) would either not make any difference, or would cause
>> immediate, obvious, breakage. Either of which is fine.

Op 14-06-2022 om 18:13 schreef Graham Knop:
> On Tue, Jun 14, 2022 at 6:02 PM Alexander Hartmaier
> <alex.hartmaier@gmail.com> wrote:
>>
>> For example https://metacpan.org/dist/DT/source/lib/DT.pm#L49
> This only cares that require returns a true value, and avoids calling
> return again in the future if so.


Nitpick, 'require' always returns a truthy value, otherwise it dies. So
this is just a cute shorthand for 'require DateTime::Format::Pg;
$HAVE_PG=1'.


HTH,

M4

On Wed, 15 Jun 2022 at 00:13, Graham Knop <haarg@haarg.org> wrote:

> On Tue, Jun 14, 2022 at 6:02 PM Alexander Hartmaier
> <alex.hartmaier@gmail.com> wrote:
> >
> > On Tue, Jun 14, 2022 at 11:33 AM Graham Knop <haarg@haarg.org> wrote:
> >>
> >> On Tue, Jun 14, 2022 at 8:15 AM Alexander Hartmaier
> >> <alex.hartmaier@gmail.com> wrote:
> >> > Look at some of the other modules using the return value of require
> from the grep.metacpan.org link.
> >>
> >> Do you have a concrete example?
>

There are plenty of cases which are effectively "`require` is used instead
of `do`", i.e. calling `require` and the subsequent code relies on the
data, rather than truth of the return value.

Some examples from just the first page of results - there are others on
that page:

https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=AWS-Lambda

my $app = require "$ENV{'LAMBDA_TASK_ROOT'}/app.psgi";
my $func = AWS::Lambda::PSGI->wrap($app);

https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=App-Alice

my $config = {};
if (-e $self->fullpath) {
$config = require $self->fullpath;

https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=App-Chart

my $aref = require App::Chart::Gtk2::IndicatorModelGenerated;

All of these are somewhat fragile: call the code twice or have something
else `require` the relevant module/file first, and they'd have problems.
However, given how often this pattern appears,
require-returns-`builtin::true` may be too disruptive if strictly enforced?

Keeping the original value _also_ doesn't seem like a good idea, `package
Example; my $should_drop_out_of_scope = ...;` for example.

On Tue, Jun 14, 2022 at 7:10 PM Tom Molesworth <tom@deriv.com> wrote:
>
> On Wed, 15 Jun 2022 at 00:13, Graham Knop <haarg@haarg.org> wrote:
>>
>> On Tue, Jun 14, 2022 at 6:02 PM Alexander Hartmaier
>> <alex.hartmaier@gmail.com> wrote:
>> >
>> > On Tue, Jun 14, 2022 at 11:33 AM Graham Knop <haarg@haarg.org> wrote:
>> >>
>> >> On Tue, Jun 14, 2022 at 8:15 AM Alexander Hartmaier
>> >> <alex.hartmaier@gmail.com> wrote:
>> >> > Look at some of the other modules using the return value of require from the grep.metacpan.org link.
>> >>
>> >> Do you have a concrete example?
>
>
> There are plenty of cases which are effectively "`require` is used instead of `do`", i.e. calling `require` and the subsequent code relies on the data, rather than truth of the return value.
>
> Some examples from just the first page of results - there are others on that page:
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=AWS-Lambda
>
> my $app = require "$ENV{'LAMBDA_TASK_ROOT'}/app.psgi";
> my $func = AWS::Lambda::PSGI->wrap($app);
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=App-Alice
>
> my $config = {};
> if (-e $self->fullpath) {
> $config = require $self->fullpath;
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=App-Chart
>
> my $aref = require App::Chart::Gtk2::IndicatorModelGenerated;
>
> All of these are somewhat fragile: call the code twice or have something else `require` the relevant module/file first, and they'd have problems. However, given how often this pattern appears, require-returns-`builtin::true` may be too disruptive if strictly enforced?

It would not be strictly enforced. It would only happen if the file
being required did `use v5.40;` or such a declaration. Most of these
cases would likely never add that declaration, and new code that did
would not be able to be used in this fragile way. If someone did add
such a declaration to their existing code, it would cause these uses
to immediately fail, which I see as an acceptable outcome.

>
> Keeping the original value _also_ doesn't seem like a good idea, `package Example; my $should_drop_out_of_scope = ...;` for example.
>

On Tue, Jun 14, 2022 at 7:10 PM Tom Molesworth <tom@deriv.com> wrote:

> On Wed, 15 Jun 2022 at 00:13, Graham Knop <haarg@haarg.org> wrote:
>
>> On Tue, Jun 14, 2022 at 6:02 PM Alexander Hartmaier
>> <alex.hartmaier@gmail.com> wrote:
>> >
>> > On Tue, Jun 14, 2022 at 11:33 AM Graham Knop <haarg@haarg.org> wrote:
>> >>
>> >> On Tue, Jun 14, 2022 at 8:15 AM Alexander Hartmaier
>> >> <alex.hartmaier@gmail.com> wrote:
>> >> > Look at some of the other modules using the return value of require
>> from the grep.metacpan.org link.
>> >>
>> >> Do you have a concrete example?
>>
>
> There are plenty of cases which are effectively "`require` is used instead
> of `do`", i.e. calling `require` and the subsequent code relies on the
> data, rather than truth of the return value.
>
> Some examples from just the first page of results - there are others on
> that page:
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=AWS-Lambda
>
> my $app = require "$ENV{'LAMBDA_TASK_ROOT'}/app.psgi";
> my $func = AWS::Lambda::PSGI->wrap($app);
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=App-Alice
>
> my $config = {};
> if (-e $self->fullpath) {
> $config = require $self->fullpath;
>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=App-Chart
>
> my $aref = require App::Chart::Gtk2::IndicatorModelGenerated;
>
> All of these are somewhat fragile: call the code twice or have something
> else `require` the relevant module/file first, and they'd have problems.
> However, given how often this pattern appears,
> require-returns-`builtin::true` may be too disruptive if strictly enforced?
>
> Keeping the original value _also_ doesn't seem like a good idea, `package
> Example; my $should_drop_out_of_scope = ...;` for example.
>
> I saw those but they confused me.
So require just returns what the loaded file returns? So in case the file
ends in 1;, the return value is 1, but some return a blessed object and
this is returned?

Is that a feature or a misuse of 'require'?

2022-6-15 16:21 Alexander Hartmaier <alex.hartmaier@gmail.com> wrote:

> On Tue, Jun 14, 2022 at 7:10 PM Tom Molesworth <tom@deriv.com> wrote:
>
>> On Wed, 15 Jun 2022 at 00:13, Graham Knop <haarg@haarg.org> wrote:
>>
>>> On Tue, Jun 14, 2022 at 6:02 PM Alexander Hartmaier
>>> <alex.hartmaier@gmail.com> wrote:
>>> >
>>> > On Tue, Jun 14, 2022 at 11:33 AM Graham Knop <haarg@haarg.org> wrote:
>>> >>
>>> >> On Tue, Jun 14, 2022 at 8:15 AM Alexander Hartmaier
>>> >> <alex.hartmaier@gmail.com> wrote:
>>> >> > Look at some of the other modules using the return value of require
>>> from the grep.metacpan.org link.
>>> >>
>>> >> Do you have a concrete example?
>>>
>>
>> There are plenty of cases which are effectively "`require` is used
>> instead of `do`", i.e. calling `require` and the subsequent code relies on
>> the data, rather than truth of the return value.
>>
>> Some examples from just the first page of results - there are others on
>> that page:
>>
>> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=AWS-Lambda
>>
>> my $app = require "$ENV{'LAMBDA_TASK_ROOT'}/app.psgi";
>> my $func = AWS::Lambda::PSGI->wrap($app);
>>
>> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=App-Alice
>>
>> my $config = {};
>> if (-e $self->fullpath) {
>> $config = require $self->fullpath;
>>
>> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=App-Chart
>>
>> my $aref = require App::Chart::Gtk2::IndicatorModelGenerated;
>>
>> All of these are somewhat fragile: call the code twice or have something
>> else `require` the relevant module/file first, and they'd have problems.
>> However, given how often this pattern appears,
>> require-returns-`builtin::true` may be too disruptive if strictly enforced?
>>
>> Keeping the original value _also_ doesn't seem like a good idea, `package
>> Example; my $should_drop_out_of_scope = ...;` for example.
>>
>> I saw those but they confused me.
> So require just returns what the loaded file returns? So in case the file
> ends in 1;, the return value is 1, but some return a blessed object and
> this is returned?
>
> Is that a feature or a misuse of 'require'?
>

I also want to know either of the following.

1. "require" ignores the return value of the .pm file to check whether it
is successful, and "require" returns builtin::true.

2. "require" ignores the return value of the .pm file to check whether it
is successful, and "require" returns the return value of the .pm file.

On Mon, Jun 06, 2022 at 11:05:59PM +0100, Neil Bowers wrote:
> This is a retrospective Pre-RFC for a proposal from Curtis, for which he submitted a draft RFC[1]. We nearly missed it when reviewing proposals in-flight in our PSC meeting last week, and decided to trigger a discussion here, to reinforce the process.
>
> Beginning and casual Perl programmers regularly get confused / caught out by the requirement to add `1;` at the end of their modules. To add to their confusion, there are plenty of modules on CPAN with humorous alternatives for "1".
>
> Curtis proposed a feature called something like yield_true, which would result in the current file yielding a true value on successful compilation. So a module could then look like this:
>
> package Zork;
> use feature 'yield_true';
>
> # code
>
> This is not a feature we’d expect people to use explicitly, but would be part of the version bundle, so you’d get it for free with a future `use v5.XY`.

Thinking about implementation, how should this behave if the included file was:

package Zork {
use feature 'yield_true';
}

remembering features (and use vX.XX) are lexical.

Or perhaps less reasonably:

package Zork;
{
{
{
use feature 'yield_true';
}
}
}

The true module on CPAN works by checking the filename between when
"true"->import() is called and when the check function for the
leaveeval is called, which a #line directive might break.

Tony

On Thu, 16 Jun 2022 at 12:29, Tony Cook <tony@develop-help.com> wrote:

> Thinking about implementation, how should this behave if the included file
> was:
>
> package Zork {
> use feature 'yield_true';
> }
>

Since it's called `yield_true` rather than `ignore_false`, I'd expect that
lexical scope to behave as if it was wrapped in `(...) or builtin::true`,
so the `require Zork;` would work as if it had been `package Zork;
builtin::true`. Similarly for nested scopes: behaving a bit like `perl
-le'print do { { { (undef) or 1 } } }'` with the true value propagating.
Presumably that would enforce scalar context: is that likely to be a
problem?

Similarly:

my $value = do { use feature 'yield_true'; undef }; # we're expecting
$value = builtin::true, yes?

This level of detail seems more appropriate for the RFC stage. Seems
there's enough interest to go beyond pre-RFC here?

Porters,

Here's what I think, on the matter of eliminating that pesky magic true value.

In "Foo.pm" we want a way to signal that when require-d, it is treated as if it had evaluated to true, even if (say) the last statement is "0;".

The biggest question, for me, is how we signal that. The mostly-undebated option here has been:
use feature 'xyzzy'; # for some value of "xyzzy"

The problem with that is that "use feature" is always lexical, but it's not clear that this makes sense lexically.
require v5.40.0; # assert version number is high enough but do not enable features

do_some_stuff;

package Foo {
use v5.40.0;
# strict is on
}

# strict is off again

more_code_here;

0;

# EOF

If the yield-true feature exists and is enabled by v5.40, what should happen here? If it's treated as if on, we're violating the expectation of lexical effect. If it's treated as off, we've created a new kind of feature that only matters at top-level scope in a file. If a programmer has written all their code inside a "package NAME BLOCK" structure, which previously would have no particular problem, they now don't fully benefit from "use vX".

All of this *makes sense*, but a large part of getting rid of the need for the "magic true value" is to avoid confusing programmers who don't want to think about the weird under-the-hood stuff here. I don't think we're avoiding enough confusion. The error "Foo.pm did not return a true value." could be worse, but it's not the best, either.

Issuing a "use vX doesn't make sense at non-top-level" also seems unappealing.

I don't have a great solution to offer. So far what I've got is:
* if "require" errors because of a false value
* and the file required did enable the feature
* but did not *explicitly* disable it, subsequently
* *then*, a warning is issued "File.pm did not return a true value. The xyzzy feature, which would eliminate this error, was enabled at line 123 but only in a limited lexical scope, ending at line 321."
I'm not in love with it.

--
rjbs

I was having similar thoughts to what Ricardo said here, back when this thread
was started.

My thought was that if the feature in discussion was being treated consistently,
then it would necessarily have to affect a lot more things.

How I interpret Perl's current behavior is that we have a general feature such
that in any lexical context, meaning a block defined by a pair of curly braces
as well as the base scope of each file, users have the choice of having explicit
return statements or having implicit return statements. In each scope, an
explicit "return" means that is the result value from executing the block/file,
and otherwise if the last statement executed in a scope isn't a "return", then
the result is implicitly what the last statement returns.

So in this context, I interpret a generalization of "yield true" to behave as if
every lexical scope or block or file has an implicit "return true;" added to the
end of it.

So when "yield true" is in effect, every block will return true instead of the
result of the last statement, unless the last statement is a "return" statement.
And even then, logically it still works as if the implicit statement is
present, but its just never executed because the explicit "return" ends the
block before its reached.

In that case, "yield true" absolutely makes sense as a lexical scope, where one
can then turn it on or off between nested scopes.

But then the question is, how much code would this break, that is relying on
implicit returns in blocks. My thought is, it would break a lot, at least in
the case of blocks used within expressions like map/grep/sort/do/etc.

So, I have an alternate proposal:

1. Treat the "yield true" feature like how we treat explicit declarations of
file encoding, in that they are explicitly NOT lexical, and that having one
anywhere in a file causes it to apply to the entire file, and/or it is only
legal for the declaration to exist at the top level of a file and not inside any
block.

2. The above-mentioned version of "yield true" is included automatically when
one says "use v5.38;" and above, meaning the only legal thing one can actually
do is optionally say "no yield_true;" (or they can still say "use yield_true;"
but it would be redundant, unless this is also provided as a CPAN module for use
with older Perls).

3. The "yield true" feature only has any effect on the top-level lexical scope
of a file, meaning what is outside of all curly brace blocks.

4. We also add the ability, if it isn't already allowed, one to use explicit
"return" statements at the top level of a file. This empowers people to
explicitly say that a file returns an explicit value which could be anything
true or false. If that exists, one can say "use 5.38;" WITHOUT having to
explicitly turn off yield_true in order to yield something else, because any
return statement at the top level would override any yield_true that may be in
effect, because the implicit "return true;" at file's end isn't reached.

What are thoughts on this?

-- Darren Duncan

On 2022-06-17 5:00 p.m., Ricardo Signes wrote:
> Porters,
>
> Here's what I think, on the matter of eliminating that pesky magic true value.
>
> In "Foo.pm" we want a way to signal that when require-d, it is treated as if it
> had evaluated to true, even if (say) the last statement is "0;".
>
> The biggest question, for me, is how we signal that.  The mostly-undebated
> option here has been:
>
> use feature 'xyzzy'; # for some value of "xyzzy"
>
>
> The problem with that is that "use feature" is always lexical, but it's not
> clear that this makes sense lexically.
>
> require v5.40.0; # assert version number is high enough but do not enable features
>
> do_some_stuff;
>
> package Foo {
> use v5.40.0;
> # strict is on
> }
>
> # strict is off again
>
> more_code_here;
>
> 0;
>
> # EOF
>
>
> If the yield-true feature exists and is enabled by v5.40, what should happen
> here?  If it's treated as if on, we're violating the expectation of lexical
> effect.  If it's treated as off, we've created a new kind of feature that only
> matters at top-level scope in a file.  If a programmer has written all their
> code inside a "package NAME BLOCK" structure, which previously would have no
> particular problem, they now don't fully benefit from "use vX".
>
> All of this /makes sense/, but a large part of getting rid of the need for the
> "magic true value" is to avoid confusing programmers who don't want to think
> about the weird under-the-hood stuff here.  I don't think we're avoiding enough
> confusion.  The error "Foo.pm did not return a true value." could be worse, but
> it's not the best, either.
>
> Issuing a "use vX doesn't make sense at non-top-level" also seems unappealing.
>
> I don't have a great solution to offer.  So far what I've got is:
>
> * if "require" errors because of a false value
> * and the file required did enable the feature
> * but did not /explicitly/ disable it, subsequently
> * /then/, a warning is issued "File.pm did not return a true value.  The xyzzy
> feature, which would eliminate this error, was enabled at line 123 but only
> in a limited lexical scope, ending at line 321."
>
> I'm not in love with it.
>
> --
> rjbs
>

On Fri, Jun 17, 2022, at 23:00, Darren Duncan wrote:
> 1. Treat the "yield true" feature like how we treat explicit declarations of
> file encoding, in that they are explicitly NOT lexical, and that having one
> anywhere in a file causes it to apply to the entire file, and/or it is only
> legal for the declaration to exist at the top level of a file and not inside any
> block.

What are you referring to when you say "how we treat explicit declarations of file encoding"?

> 4. We also add the ability, if it isn't already allowed, one to use explicit
> "return" statements at the top level of a file.

This already exists as can be trivially verified:
$ echo 1 > foo.pm
$ echo "return 0; 1" > bar.pm
$ perl -I . -Mfoo -e0
$ perl -I . -Mbar -e0
bar.pm did not return a true value.
BEGIN failed--compilation aborted.

--
rjbs

On 2022-06-17 8:10 p.m., Ricardo Signes wrote:
> On Fri, Jun 17, 2022, at 23:00, Darren Duncan wrote:
>> 1.  Treat the "yield true" feature like how we treat explicit declarations of
>> file encoding, in that they are explicitly NOT lexical, and that having one
>> anywhere in a file causes it to apply to the entire file, and/or it is only
>> legal for the declaration to exist at the top level of a file and not inside any
>> block.
>
> What are you referring to when you say "how we treat explicit declarations of
> file encoding"?

I refer to when we say "use utf8;" or "use encoding" etc.

I know there have been other discussions about improving the behavior of this,
but one key takeaway I had was that in practice it didn't really seem to be a
good idea to support a file that was partly one encoding and partly another, and
so best practice would be that any declarations like "use utf8" etc should
necessarily be referring to the whole file and not a lesser lexical scope.

So I'm saying that "yield_true" should be the same in the sense that while
logically it COULD be lexical, there's in practice no good reason for it to be
so, or if there was, it would be a very different feature than one designed to
just remove the need for a "1;", that different feature would be mainly about
altering how subroutines behave.

-- Darren Duncan

Hi there,

On Fri, 17 Jun 2022, Darren Duncan wrote:

> ...
> What are thoughts on this?

So far it seems like a case of out of the frying pan and into the fire.

--

73,
Ged.

On Fri, Jun 17, 2022, at 23:44, Darren Duncan wrote:
> On 2022-06-17 8:10 p.m., Ricardo Signes wrote:
> > On Fri, Jun 17, 2022, at 23:00, Darren Duncan wrote:
> >> 1. Treat the "yield true" feature like how we treat explicit declarations of
> >> file encoding, in that they are explicitly NOT lexical, and that having one
> >> anywhere in a file causes it to apply to the entire file, and/or it is only
> >> legal for the declaration to exist at the top level of a file and not inside any
> >> block.
> >
> > What are you referring to when you say "how we treat explicit declarations of
> > file encoding"?
>
> I refer to when we say "use utf8;" or "use encoding" etc.

Then you are mistaken, because "use utf8" is lexically scoped.
dinah:~$ cat length
use v5.36.0;

my $str1 = do { use utf8; "????" };
my $str2 = do { "????" };

say length $str1;
say length $str2;

dinah:~$ perl that-program-above
1
4

encoding.pm has been deprecated for nine years and fatal to use for seven. It's not a good thing to cite as example. But also, if you travel back in time and test it, its behavior is terrible and a good example for why "looks lexical, actually silently file-scoped" is a bad idea. It only affects the file *after it appears* in the file. This is one of the points we were going to pains to deal with when discussing source::encoding: how do you ensure whole-document coherency?

> So I'm saying that "yield_true" should be the same in the sense that while logically it COULD be lexical, there's in practice no good reason for it to be so, or if there was, it would be a very different feature than one designed to
> just remove the need for a "1;", that different feature would be mainly about altering how subroutines behave.

What am trying to do is not make it lexical, but to anticipate places where the user will be surprised and either make them not surprising or, at least, tell the user what happened.

--
rjbs

On Fri, Jun 17, 2022 at 08:00:10PM -0400, Ricardo Signes wrote:
> Porters,
>
> Here's what I think, on the matter of eliminating that pesky magic true value.

And here's what I think.

We should be guided by avoiding, as far as possible, edge/special cases,
a.k.a. the principle of least surprise.

So I propose:

1) that the yield_true feature is strictly lexically scoped. Because
otherwise it's a special case.

99.9% of the time it will be enabled at the top of the src file, so no one
will care much. In the rare case that someone does

{
use v5.40;
... something relying on 5.40 syntax ...
}
... normal perl ...
0;

then regardless whether their code makes much sense of not, it should do
as expected, and croak with "Foo.pm did not return a true value".

2) that, regardless of whether the require returns via an explicit
'return', or by implicitly falling off the end of the src file, whether
perl does the "croak if false" test is governed purely by whether
'yield_true' was in scope at the last statement executed. I.e. we don't
distinguish between implicit and explicit returns - again, otherwise it's
a special case.

If someone really wants the old behaviour under some circumstances, they
can do either:

die "I detected a problem while executing Foo.pm" if $bad;

or to more exactly reproduce the old behaviour,

use v5.40;
...

if ($bad) {
no feature 'yield_true';
return 0;
}



--
A power surge on the Bridge is rapidly and correctly diagnosed as a faulty
capacitor by the highly-trained and competent engineering staff.
-- Things That Never Happen in "Star Trek" #9