Mailing List Archive

On Fri, Jun 24, 2022 at 4:04 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> On Sun, Jun 19, 2022, at 08:23, Dave Mitchell wrote:
>
> 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.
>
>
> I think you and I are in agreement, except for one small matter: I think
> that it'd be useful to say "module evaluated to false, despite having at
> some point enabled yield true, which probably indicates a mistake." If
> this ends up being onerous, I think it's something we can do without. But
> I think it will help users who do what Ovid mentioned doing: writing all
> their code in a block. The feature under discussion is the only one that
> would really be affected by writing your code that way. That's why I think
> it's plausible it's happening.
>
> Why don't we start with just implementing the basic feature and then we
> have a year to think more about the warning if we want. ????
>
> Also, we know it needs a name. I suggest 'module_true'. If the feature
> is on, then this module will be treated as evaluating true. I don't want
> to say 'require_ignores_false' or something because that could imply it
> changes the behavior of "require" in this scope.
>
> 'module_true' sounds very generic.
Having 'require' as part of its name would be good, as it affects how
require is behaving.

I don't get why you wrote that one shouldn't imply that its behavior
changes because that's just what it does:
- "require" ignores the return value to determine if the module was
successfully loaded.

On Mon, Jun 27, 2022 at 10:10 AM Alexander Hartmaier
<alex.hartmaier@gmail.com> wrote:
>
> On Fri, Jun 24, 2022 at 4:04 PM Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>>
>> On Sun, Jun 19, 2022, at 08:23, Dave Mitchell wrote:
>>
>> 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.
>>
>>
>> I think you and I are in agreement, except for one small matter: I think that it'd be useful to say "module evaluated to false, despite having at some point enabled yield true, which probably indicates a mistake." If this ends up being onerous, I think it's something we can do without. But I think it will help users who do what Ovid mentioned doing: writing all their code in a block. The feature under discussion is the only one that would really be affected by writing your code that way. That's why I think it's plausible it's happening.
>>
>> Why don't we start with just implementing the basic feature and then we have a year to think more about the warning if we want. ????
>>
>> Also, we know it needs a name. I suggest 'module_true'. If the feature is on, then this module will be treated as evaluating true. I don't want to say 'require_ignores_false' or something because that could imply it changes the behavior of "require" in this scope.
>>
> 'module_true' sounds very generic.
> Having 'require' as part of its name would be good, as it affects how require is behaving.
>
> I don't get why you wrote that one shouldn't imply that its behavior changes because that's just what it does:
> - "require" ignores the return value to determine if the module was successfully loaded.

It does not change how "require" acts in the scope of the feature. It
changes how "require" acts when returning from where the feature is
active.

On Mon, Jun 27, 2022 at 10:17 AM Graham Knop <haarg@haarg.org> wrote:

> On Mon, Jun 27, 2022 at 10:10 AM Alexander Hartmaier
> <alex.hartmaier@gmail.com> wrote:
> >
> > On Fri, Jun 24, 2022 at 4:04 PM Ricardo Signes <
> perl.p5p@rjbs.manxome.org> wrote:
> >>
> >> On Sun, Jun 19, 2022, at 08:23, Dave Mitchell wrote:
> >>
> >> 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.
> >>
> >>
> >> I think you and I are in agreement, except for one small matter: I
> think that it'd be useful to say "module evaluated to false, despite having
> at some point enabled yield true, which probably indicates a mistake." If
> this ends up being onerous, I think it's something we can do without. But
> I think it will help users who do what Ovid mentioned doing: writing all
> their code in a block. The feature under discussion is the only one that
> would really be affected by writing your code that way. That's why I think
> it's plausible it's happening.
> >>
> >> Why don't we start with just implementing the basic feature and then we
> have a year to think more about the warning if we want. ????
> >>
> >> Also, we know it needs a name. I suggest 'module_true'. If the
> feature is on, then this module will be treated as evaluating true. I
> don't want to say 'require_ignores_false' or something because that could
> imply it changes the behavior of "require" in this scope.
> >>
> > 'module_true' sounds very generic.
> > Having 'require' as part of its name would be good, as it affects how
> require is behaving.
> >
> > I don't get why you wrote that one shouldn't imply that its behavior
> changes because that's just what it does:
> > - "require" ignores the return value to determine if the module was
> successfully loaded.
>
> It does not change how "require" acts in the scope of the feature. It
> changes how "require" acts when returning from where the feature is
> active.
>

Examples are king, just explained your text to myself while I wanted to
write 'the other way round', but your're correct:

package A;
# in the scope of package A
use 'require_ignore_false';


# no true return value here, let's make it explicitly return false for
clarity
0;

package B:
my $rv = require 'A';
# $rv is 0 which is false in boolean context

# no error in scope of package B although false is returned

Hope that helps others as well to clarify.

On Mon, Jun 27, 2022 at 01:12:17PM +0200, Alexander Hartmaier wrote:
> package B:
> my $rv = require 'A';
> # $rv is 0 which is false in boolean context
>
> # no error in scope of package B although false is returned


My mind has been changed by Graham Knop's observations that:

* the return value of require is most often used like:

if (eval { require $module }) { ... }

* that if a file is require'd for a second time, the code isn't called
again and the 'true' value (i.e. !!1) is returned rather than whatever
was returned the first time. For example:

Foo.pm:
package Foo;
5;

$ perl -le'print require Foo for 1..2'
5
1

So relying on the actual return value is a poor practice which we should
seek to eliminate. So I now think that the single change in behaviour in
perl should be:

At the point in the core which does the return-from-require
processing, it's behaviour should change from:

if the return value is false, croak, else return the value to the
caller of 'require'.

to:

if 'require_returns_true' was in scope at the point where require
explicitly or implicitly returned:

throw away the return value and return !!1 to the caller of
'require'

else

as before: if the return value is false, croak, else return
the value to the caller of 'require'.


I'm not convinced that having a warning when returning a false value would
be useful. I suspect that most uses of 'use v5.40' will be in new code
(rather than retrofitting an existing module) where a warning won't be
particularly useful. Instead it could generate false positives - for
example, if the last line in Foo.pm file is:

$Foo::some_flag = calc_flag();

then the warning will surface only if calc_flag() returns false,
which might not happen during testing.

So such a warning would only potentially be useful in old code which has
been retrofitted with 'use v5.40', and then only on those rare modules
which actually use a false return to signal failure. I think this is rare
enough to not outweigh the problem of false positives in new code.


--
31 Dec 1661: "I have newly taken a solemne oath about abstaining from plays".
1 Jan 1662: "And after ... we went by coach to the play".
-- The Diary of Samuel Pepys

On Tue, 28 Jun 2022 10:29:13 +0100
Dave Mitchell <davem@iabyn.com> wrote:

> So I now think that the single change in
> behaviour in perl should be:
...
> to:
>
> if 'require_returns_true' was in scope at the point where
> require explicitly or implicitly returned:
>
> throw away the return value and return !!1 to the caller
> of 'require'
>
> else
>
> as before: if the return value is false, croak, else
> return the value to the caller of 'require'.

Yes; that all sounds sensible.

> I'm not convinced that having a warning when returning a false value
> would be useful. I suspect that most uses of 'use v5.40' will be in
> new code (rather than retrofitting an existing module) where a
> warning won't be particularly useful. Instead it could generate false
> positives - for example, if the last line in Foo.pm file is:
>
> $Foo::some_flag = calc_flag();
>
> then the warning will surface only if calc_flag() returns false,
> which might not happen during testing.
>
> So such a warning would only potentially be useful in old code which
> has been retrofitted with 'use v5.40', and then only on those rare
> modules which actually use a false return to signal failure. I think
> this is rare enough to not outweigh the problem of false positives in
> new code.

Also agree.

This feels like it's veering towards some kind of agreement enough that
we should write up a real RFC for the idea.

That, and my "lexically_export" should keep me busy today ;)

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Tue, 28 Jun 2022 11:07:34 +0100
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> This feels like it's veering towards some kind of agreement enough
> that we should write up a real RFC for the idea.

Actually it seems Ovid already started writing one up:

https://github.com/Perl/RFCs/pull/20

I've added some comments.

Ovid: Do you think you'll be able to tidy this one up and aim it
towards agreement with the discussions here, or should I create a new
one?

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Wed, 29 Jun 2022 15:16:45 +0100
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> On Tue, 28 Jun 2022 11:07:34 +0100
> "Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:
>
> > This feels like it's veering towards some kind of agreement enough
> > that we should write up a real RFC for the idea.
>
> Actually it seems Ovid already started writing one up:
>
> https://github.com/Perl/RFCs/pull/20

Oops; I have been a victim of the multiple-clipboards "feature" of X11.

I meant

https://github.com/Perl/RFCs/pull/16

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Wed, Jun 29, 2022 at 4:16 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> Actually it seems Ovid already started writing one up:
>
> https://github.com/Perl/RFCs/pull/20
>
> I've added some comments.
>
> Ovid: Do you think you'll be able to tidy this one up and aim it
> towards agreement with the discussions here, or should I create a new
> one?


I've tidied it up based on your feedback. If you feel a new one would be
better, that's fine, too. I'd just be happy to see it get in to core.

Curtis "Ovid" Poe
CTO, All Around the World
World-class software development and consulting
https://allaroundtheworld.fr/

On Sat, Jun 11, 2022 at 09:37:00AM +0100, 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
>
> 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;
>     }
>

And it sounds like this is use case for `do`, rather than `require`.

--
Philippe Bruhat (BooK)

No matter how you dress a cow, it still gives milk.
(Moral from Groo The Wanderer #46 (Epic))

On Sat, Jun 11, 2022 at 02:01:35PM -0600, Karl Williamson wrote:
>
> 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.
>

Here's my list of excuses:

1. Acme ;-)
2. Back then, I couldn't find another way to get the list of all Unicode
character names. I believe the functions in Unicode::UCD take a
codepoint as parameter, but provide no way of getting the whole list.
Is there a better way?

--
Philippe Bruhat (BooK)

When the employee is a fool, so is the employer.
(Moral from Groo The Wanderer #26 (Epic))

On Sat, Jun 18, 2022 at 11:13:18AM -0400, Ricardo Signes wrote:
>
> my $str1 = do { use utf8; "????" };
> my $str2 = do { "????" };

If I understand correctly, `use utf8` is less about the encoding of the
file (Perl code is ascii anyway), and more about what the literal
strings in the lexical scope actually contain (either a utf8 string, or
a byte stream), right?

--
Philippe Bruhat (BooK)

The best thing about being apart is getting together again.
(Moral from Groo The Wanderer #39 (Epic))

On Wed, Aug 3, 2022 at 11:59 AM Philippe Bruhat (BooK) <book@cpan.org>
wrote:

> On Sat, Jun 18, 2022 at 11:13:18AM -0400, Ricardo Signes wrote:
> >
> > my $str1 = do { use utf8; "????" };
> > my $str2 = do { "????" };
>
> If I understand correctly, `use utf8` is less about the encoding of the
> file (Perl code is ascii anyway), and more about what the literal
> strings in the lexical scope actually contain (either a utf8 string, or
> a byte stream), right?
>

No it is the encoding of the file. Perl code is not ASCII, it's bytes (you
can use non-ASCII bytes in symbols as long as they end up being interpreted
as word characters). Without use utf8, the bytes are interpreted as
codepoints with the identical value (which due to the mapping being
identical, is essentially a process of decoding it from ISO-8859-1). With
use utf8, the bytes are interpreted in Perl's internal upgraded encoding,
which essentially decodes it from UTF-8.

Perl has no concept of the meaning of what strings contain, they logically
contain a series of codepoints either way. use utf8 just changes how those
codepoints are derived from the bytes of the source code, along with the
rest of the code.

-Dan

Porters,

I have replaced the PR for "yield true" with one that provides more specifics, based on suggestions from Dave M. that seem sufficient and which he says would be easy to implement. I have moved it to exploratory status, but I don't expect much more exploration or discussion is required. "Surely" we're about ready to receive an implementation?

You can see it on GitHub <https://github.com/Perl/RFCs/pull/27>.

--
rjbs