Mailing List Archive

On Wed, Aug 11, 2021 at 9:21 AM H.Merijn Brand <perl5@tux.freedom.nl> wrote:

> Is it an RFC if it is based on something that already existed?
>
> Paul asked me on IRC and I realized times have changed. We have a
> renewed community with a new organization, and new ways forward.
>
> We also have learned from the past and we are trying to keep up with
> the future(s).
>
> So, with the last public mail on the subject being from Rik on this
> mailing list on 18 Feb 2013, I will just ask if there are votes in
> favor of bringing err/dor as low-precedence // back into the language
>
> ! not
> || or
> && and
> // dor (or err or whatever)
> ^ xor
>
> IIRC there were two issues that cause this new keyword not to land:
>
> 1. No conclusive agreement on the name "dor" or "err"
>
> 2. No agreement on the state (builtin keyword or weak keyword)
>
> History:
>
> • "err" as low-precedence defined-or was introduced somewhere between
> 5.8 and 5.10, probably mid 2002. The first cleaned-up patch I found
> was from 26-07-2002. The word "err" was chosen as it sounds like
> "or". Not a good argument, but whatever. It was implemented as what
> was called a weak keyword. The internals refer to OP_DOR (defined
> or), so the rename to "dor" was suggested by Schwern on 05-09-2007.
> By that time all in favor of the low-precedence "err" were already
> used to the word "err" and really didn't care.
>
> A lot of water has flowed since and neither "err" nor "dor" ever made
> it to a stable version of Perl as builtin keyword.
>
> • The most recent commit dealing with err/dor was from 11-12-2020!
> where the last remnants of KEY_err where removed from the tokenizer
>
>
> I personally would *LOVE* to see it return to the language. I now know
> Paul Johnson would too.
>
>
>
> https://www.cpan.org/authors/id/H/HM/HMBRAND/ still holds
> the patch files to include defined-or in perl-5.8.1 .. 5.8.9
>

I think this would be useful, but have no strong feelings toward whether
it's added or the name.

-Dan

On 8/11/21 10:33 AM, Dan Book wrote:
> On Wed, Aug 11, 2021 at 9:21 AM H.Merijn Brand <perl5@tux.freedom.nl
> <mailto:perl5@tux.freedom.nl>> wrote:
>
> Is it an RFC if it is based on something that already existed?
>
> Paul asked me on IRC and I realized times have changed. We have a
> renewed community with a new organization, and new ways forward.
>
> We also have learned from the past and we are trying to keep up with
> the future(s).
>
> So, with the last public mail on the subject being from Rik on this
> mailing list on 18 Feb 2013, I will just ask if there are votes in
> favor of bringing err/dor as low-precedence // back into the language
>
>   !     not
>   ||    or
>   &&    and
>   //    dor (or err or whatever)
>   ^     xor
>
> IIRC there were two issues that cause this new keyword not to land:
>
>  1. No conclusive agreement on the name "dor" or "err"
>
>  2. No agreement on the state (builtin keyword or weak keyword)
>
> History:
>
> • "err" as low-precedence defined-or was introduced somewhere between
>   5.8 and 5.10, probably mid 2002. The first cleaned-up patch I found
>   was from 26-07-2002. The word "err" was chosen as it sounds like
>   "or". Not a good argument, but whatever. It was implemented as what
>   was called a weak keyword. The internals refer to OP_DOR (defined
>   or), so the rename to "dor" was suggested by Schwern on 05-09-2007.
>   By that time all in favor of the low-precedence "err" were already
>   used to the word "err" and really didn't care.
>
> A lot of water has flowed since and neither "err" nor "dor" ever made
> it to a stable version of Perl as builtin keyword.
>
> • The most recent commit dealing with err/dor was from 11-12-2020!
>   where the last remnants of KEY_err where removed from the tokenizer
>
>
> I personally would *LOVE* to see it return to the language. I now know
> Paul Johnson would too.
>
>
>
> https://www.cpan.org/authors/id/H/HM/HMBRAND/
> <https://www.cpan.org/authors/id/H/HM/HMBRAND/> still holds
>   the patch files to include defined-or in perl-5.8.1 .. 5.8.9
>
>
> I think this would be useful, but have no strong feelings toward whether
> it's added or the name.
>
> -Dan

Since the last time this came up was several years ago, would it be
possible to provide a one-paragraph explanation for the rationale for
the feature?

* H.Merijn Brand <perl5@tux.freedom.nl> [2021-08-11 15:20:21 +0200]:

> Is it an RFC if it is based on something that already existed?
>
> Paul asked me on IRC and I realized times have changed. We have a
> renewed community with a new organization, and new ways forward.
>
> We also have learned from the past and we are trying to keep up with
> the future(s).
>
> So, with the last public mail on the subject being from Rik on this
> mailing list on 18 Feb 2013, I will just ask if there are votes in
> favor of bringing err/dor as low-precedence // back into the language
>
> ! not
> || or
> && and
> // dor (or err or whatever)
> ^ xor
>
> IIRC there were two issues that cause this new keyword not to land:
>
> 1. No conclusive agreement on the name "dor" or "err"

Why do we make things difficult on ourselves and do silly things like
make the "defined or" look like, err-or? Is it an error?

>
> 2. No agreement on the state (builtin keyword or weak keyword)

Maybe stay away from overloaded terms like "err" and you'll get some
more agreement. "dor" is fine with me. "err"? >_>...

And IIRC, "//" is not a logical operator; it's more like assignment shorthand. So
does it even need a lower precedent "word" to represent it? In what cases
might this be useful? Maybe we can consider the shorthand "ass" (for assignment)
in this case?

Cheers,
Brett
>
> History:
>
> ? "err" as low-precedence defined-or was introduced somewhere between
> 5.8 and 5.10, probably mid 2002. The first cleaned-up patch I found
> was from 26-07-2002. The word "err" was chosen as it sounds like
> "or". Not a good argument, but whatever. It was implemented as what
> was called a weak keyword. The internals refer to OP_DOR (defined
> or), so the rename to "dor" was suggested by Schwern on 05-09-2007.
> By that time all in favor of the low-precedence "err" were already
> used to the word "err" and really didn't care.
>
> A lot of water has flowed since and neither "err" nor "dor" ever made
> it to a stable version of Perl as builtin keyword.
>
> ? The most recent commit dealing with err/dor was from 11-12-2020!
> where the last remnants of KEY_err where removed from the tokenizer
>
>
> I personally would *LOVE* to see it return to the language. I now know
> Paul Johnson would too.
>
>
>
> https://www.cpan.org/authors/id/H/HM/HMBRAND/ still holds
> the patch files to include defined-or in perl-5.8.1 .. 5.8.9
>
> --
> H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
> using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux
> https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
>



--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

On Wed, 11 Aug 2021 10:41:58 -0400, James E Keenan <jkeenan@pobox.com>
wrote:

> Since the last time this came up was several years ago, would it be
> possible to provide a one-paragraph explanation for the rationale for
> the feature?

Consistency. Essentially, when // was introduced, the low-level
operator was forgotten.

In my life as perl user I have never ever needed or used xor, but I
have used err while it was defined many many times. It is about making
easy (but ugly) things even easier and more consistent.

Low-level precedence operators enable coders to use less line noise.

foreach my $value (get_values ($foo)) {
my $v = convert_value ($value) dor next; # "" and 0 are ok
# ...
}

sub foo {
my $v = shift dor return;
# ...
}

There are two camps in using and/if or/unless

warn "Blah" if $error;
vs
$error and warn "Blah";

I am *firmly* in the second, as that fits how I think.

I also am a strong proponent of using early return instead of the (in
my perception very stupid) only-one-return.

sub foo {
if (defined $foo) {
# 50 lines of code
}
else {
die "foo was not defined";
}
}

vs

sub foo {
defined $foo or return;

# 50 lines of code
}

with dor next to and and or, the code stay clean, readable,
maintainable and more consistent. In the if/else example I would
not care, as the code already looks like a mess (to me).

--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org

On Wed, Aug 11, 2021, at 11:00 AM, Oodler 577 via perl5-porters wrote:
> And IIRC, "//" is not a logical operator; it's more like assignment shorthand. So
> does it even need a lower precedent "word" to represent it? In what cases
> might this be useful? Maybe we can consider the shorthand "ass" (for assignment)
> in this case?

// is a logical operator. Beyond the fact that, as an analog to || and &&, it is obviously performing logic, it's documented as "Logical Defined-Or" in the manual. It has nothing to do with assignment. Perhaps you are thinking of "//=", the combining assignment form that many binary operators have. Or maybe you just thought it would be funny to say a rude word.

Brett, you seem to respond to an inordinately high percentage of threads on this list. When you do, the content often seems to be, "I don't know anything about this topic, but I would like to weigh in." This is very irritating.

Larry Wall's original newsreader for Usenet provided this warning when you posted:
> This program posts news to thousands of machines throughout the entire civilized world. Your message will cost the net hundreds if not thousands of dollars to send everywhere. Please be sure you know what you are doing.

Please consider, seriously, what value you think you are contributing to this list, before posting again.

--
rjbs

* Ricardo Signes <perl.p5p@rjbs.manxome.org> [2021-08-13 16:23:38 -0400]:

> On Wed, Aug 11, 2021, at 11:00 AM, Oodler 577 via perl5-porters wrote:
> > And IIRC, "//" is not a logical operator; it's more like assignment shorthand. So
> > does it even need a lower precedent "word" to represent it? In what cases
> > might this be useful? Maybe we can consider the shorthand "ass" (for assignment)
> > in this case?
>
> // is a logical operator. Beyond the fact that, as an analog to || and &&, it is obviously performing logic, it's documented as "Logical Defined-Or" in the manual. It has nothing to do with assignment. Perhaps you are thinking of "//=", the combining assignment form that many binary operators have. Or maybe you just thought it would be funny to say a rude word.

Yes, my mistake. I was thinking of //=. Regardless "err" as the
"word" for "//" is almost as boneheaded as using "===" for something
that does not mean what it means in JavaScript. I mean that no one
spoke up some months ago about that potential train wreck still boggles
my mind.

>
> Brett, you seem to respond to an inordinately high percentage of threads on this list. When you do, the content often seems to be, "I don't know anything about this topic, but I would like to weigh in." This is very irritating.

I'm not sure how to respond here. I feel like I know things that
might be value-add. Saying rude words is just my way of saying,
"this is a bad idea".

>
> Larry Wall's original newsreader for Usenet provided this warning when you posted:
> > This program posts news to thousands of machines throughout the entire civilized world. Your message will cost the net hundreds if not thousands of dollars to send everywhere. Please be sure you know what you are doing.

My emails are not costing anyone anything. Use an email filter if
you don't want to read my words. What costs people money is no one
calling out potentally harmful things. In this case, "err" as the
short word for the lower precedent "//".

If this is related to other comments I might have made recently on
non-email channels; my motivation is the same. To point out things
that I see, which apparently the ones with the talking sticks do
not. If others with similar observations stepped up, then you'd
not hear a peep out of me.

>
> Please consider, seriously, what value you think you are contributing to this list, before posting again.

When I post I believe I am adding value, usually; this whole reply
is a valueless response to a valueless jab. While it might make
you feel better and get some people off your back, it just ends up
being a waste of time for everyone. And kills more electrons, and
apparently costs billions of dollars in the process.

I don't want to waste my time or anyone else's time "fighting" over
this kind of stuff.

This also could have been a private email, in which case I would have
responded in a much more polite and conciliatory way.

Cheers,
Brett

>
> --
> rjbs

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

On Sat, Aug 14, 2021 at 12:46 AM Oodler 577 via perl5-porters <
perl5-porters@perl.org> wrote:

> > Larry Wall's original newsreader for Usenet provided this warning when
> you posted:
> > > This program posts news to thousands of machines throughout the entire
> civilized world. Your message will cost the net hundreds if not thousands
> of dollars to send everywhere. Please be sure you know what you are doing.
>
> My emails are not costing anyone anything.


They do. They cost us time. And we can't always ignore them either because
they can derail the discussion if we do.


> > Please consider, seriously, what value you think you are contributing to
> this list, before posting again.
>
> When I post I believe I am adding value, usually;


This might sound like a strange question, but why do you believe so?
Opinions aren't valuable by themselves, if only because everyone has them.
I would argue they have even less value than ideas.

Most other people don't respond nearly as much on this list as you do
because they mostly limit themselves to their areas of expertise. In fact
it's often the most knowledgeable people whom you will hear the least in
discussions. I think your contributions would be much more valuable if you
spent the same total effort on a tenth of the amount of emails.


> this whole reply
> is a valueless response to a valueless jab. While it might make
> you feel better and get some people off your back


It is not a jab, and if you really think it makes him feel better then I
think you missed his point entirely.

Leon

Hi Brett,
> Saying rude words is just my way of saying, "this is a bad idea".

p5p has roughly 500 subscribers who are all over the world. Rude words are going to come across as just rude to a decent percentage of readers. If someone uses rude words in an email to me, unless they’re a close friend I’ll assume either (a) they think I’m an idiot, or (b) they’re angry with me.

p5p is not a place for rude words.

> My emails are not costing anyone anything

Oh but they are.

At a minimum they cost peoples’ time to read.

And sometimes it’s hard to know what point you’re trying to make. And it’s frustrating to read a long email from you that ends with something like "oh, I guess I just don’t know". When I write an email that ends like that, I don’t send it – I delete it. Or I save the draft, maybe sleep on it, bounce it off someone, and only send it when I do know what point I want to make. I have a bunch of draft p5p emails that I haven’t sent yet because they’re not ready, and I don’t want to waste peoples’ time.

And they also cost in terms of the signal/noise ratio of p5p. Long emails that don’t contribute to a discussion are noise. They’re noise in that thread, but they also increase the perception of p5p as a noisy place. Multiple past contributors have said they’ve left/disengaged-from the list because the signal/noise ratio had declined too far. Furthermore, when the signal/noise ratio is low, it puts people off from joining discussions, or starting new ones; this can result in a downward spiral.

p5p is not a place for throwing round random ideas related to programming languages. We want to make the best use of the limited resources we have available, to make Perl better for all of us. Please think about your emails in that context before sending them.

If you want to send something to p5p, start off by writing the final line which summarises the point you want to make. Then write an email that leads to that point. Save the draft and wait 24 hours. Read any messages that have come in the meantime. Edit your email. Is your message going to move the discussion forward? If you really think so, send it. For the next 4 weeks, try and limit yourself: only send 2 messages to p5p per week.

Neil

On Wed, Aug 11, 2021 at 05:27:16PM +0200, H.Merijn Brand wrote:
> On Wed, 11 Aug 2021 10:41:58 -0400, James E Keenan <jkeenan@pobox.com>
> wrote:
>
> > Since the last time this came up was several years ago, would it be
> > possible to provide a one-paragraph explanation for the rationale for
> > the feature?
>
> Consistency. Essentially, when // was introduced, the low-level
> operator was forgotten.
>
> In my life as perl user I have never ever needed or used xor, but I
> have used err while it was defined many many times. It is about making
> easy (but ugly) things even easier and more consistent.
>
> Low-level precedence operators enable coders to use less line noise.
>
> foreach my $value (get_values ($foo)) {
> my $v = convert_value ($value) dor next; # "" and 0 are ok
> # ...
> }

I will suggest to anyone who cares to listen that low-level operators
should only be used for flow control and high-level operators should
only be used in conditions. Not having a low-level // operator breaks
this consistency.

In the example above // may safely be used, but only because of the
parentheses around $value.

In the analogous real-world example which caused me to publicly lament
the lack of this feature convert_value returned either undef or a scalar
blessed into a class which overloaded "" in a relatively expensive
fashion. This meant that

my $v = convert_value ($value) or next;

whilst functionally correct, was expensive in the case of a
true value being returned and the "or" needed to be changed to //
despite the function never returning any other false value. I would
assume that dor would not call the stringification method on the object.

(Yes, the class should probably overload bool, or turn off fallback, or
..., but that's not the point here.)

So the arguments for a low-level // operator are basically the same as
the arguments for any other low-level operator. Plus consistency.

--
Paul Johnson - paul@pjcj.net

* Neil Bowers <neilb@neilb.org> [2021-08-15 00:42:08 +0100]:

> If you want to send something to p5p, start off by writing the final line which summarises the point you want to make.

Sure, here's my point: naming something "err" that is not related
to an error or exception is a bad idea.

I will take your suggestions on being more laconic in the future.

All that other stuff is a distraction; I don't engage in ego driven
conversations. Because at the end of the day it's not about me,
it's about the past, present, and future of perl/Perl and *someone*
saying *something* when necessary.

Cheers,
Brett

> Neil

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

H.Merijn Brand wrote on 11 August:
>
> Consistency. Essentially, when // was introduced, the low-level
> operator was forgotten.
>
> In my life as perl user I have never ever needed or used xor, but I
> have used err while it was defined many many times. It is about making
> easy (but ugly) things even easier and more consistent.

Considering

defined $foo or next;

and

$foo dor next;

the former seems much more clean and readable to me. `dor` or `dand` aren't terms that are really established anywhere AFAIK (unlike `xor`, which has been around forever). And `err` is misleading. However, the following doesn't assign the value of $foo; you'd need `dor` or `//` for that:

my $bar = defined $foo or next;

So `dor` does add some small value to Perl. I just don't much like the name. I'm wondering if the operator could be named `definedor` instead, or if perhaps the following construct (which is currently a compile error) should be treated specially:

my $bar = $foo defined or next;


--
Arne Johannessen

On Aug 17, 2021, at 7:22 AM, Arne Johannessen <arne-9544@thaw.de> wrote:

> Considering
>
> defined $foo or next;
>
> and
>
> $foo dor next;
>
> the former seems much more clean and readable to me. `dor` or `dand` aren't terms that are really established anywhere AFAIK (unlike `xor`, which has been around forever).

What if it were spelled `d-or`?

Josh

Op 17-08-2021 om 13:22 schreef Arne Johannessen:
> H.Merijn Brand wrote on 11 August:
>> Consistency. Essentially, when // was introduced, the low-level
>> operator was forgotten.
>>
>> In my life as perl user I have never ever needed or used xor, but I
>> have used err while it was defined many many times. It is about making
>> easy (but ugly) things even easier and more consistent.
> Considering
>
> defined $foo or next;
>
> and
>
> $foo dor next;
>
> the former seems much more clean and readable to me. `dor` or `dand` aren't terms that are really established anywhere AFAIK (unlike `xor`, which has been around forever). And `err` is misleading. However, the following doesn't assign the value of $foo; you'd need `dor` or `//` for that:
>
> my $bar = defined $foo or next;

Nit pick: As that variable is introduced on that line, it really doesn't
matter if the assignment is done or not. I imagine you meant:


my $bar;

while (....) {

  ...

  $bar = $foo dor next;

  ...

}


>
> So `dor` does add some small value to Perl. I just don't much like the name. I'm wondering if the operator could be named `definedor` instead, or if perhaps the following construct (which is currently a compile error) should be treated specially:
>
> my $bar = $foo defined or next;
>

There is something to be said for symetry, so introducing a low
precedence operator for // makes sense. In that context, this
alternative syntax is an exception, and exceptions often do not make a
language better.


That said, I actually like it. It's Perlish quirky. :)


HTH,

M4

On Tue, 17 Aug 2021, Arne Johannessen wrote:
> H.Merijn Brand wrote on 11 August:
> >
> > Consistency. Essentially, when // was introduced, the low-level
> > operator was forgotten.
> >
> > In my life as perl user I have never ever needed or used xor, but I
> > have used err while it was defined many many times. It is about making
> > easy (but ugly) things even easier and more consistent.
>
> Considering
>
> defined $foo or next;
>
> and
>
> $foo dor next;
>
> the former seems much more clean and readable to me. `dor` or `dand` aren't terms that are really established anywhere AFAIK (unlike `xor`, which has been around forever). And `err` is misleading. However, the following doesn't assign the value of $foo; you'd need `dor` or `//` for that:
>
> my $bar = defined $foo or next;
>
> So `dor` does add some small value to Perl. I just don't much like the name. I'm wondering if the operator could be named `definedor` instead, or if perhaps the following construct (which is currently a compile error) should be treated specially:
>
> my $bar = $foo defined or next;
>

FWIW, the name for the "dor" operator in Raku is "orelse", which at least
to me sounds good and reminds me somewhat of the implicit ternary that is
behind the dor:

defined($foo) ? $foo : $bar
$foo orelse $bar

Best,
Tobias

--
"There's an old saying: Don't change anything... ever!" -- Mr. Monk

> FWIW, the name for the "dor" operator in Raku is "orelse",
> which at least to me sounds good and reminds me somewhat
> of the implicit ternary that is behind the dor:
>
> defined($foo) ? $foo : $bar
> $foo orelse $bar
>
>Best,
>Tobias
+1
Carl Friedberg

* Carl Friedberg <carl@comets.me> [2021-08-17 19:47:00 +0000]:

> > FWIW, the name for the "dor" operator in Raku is "orelse",
> > which at least to me sounds good and reminds me somewhat
> > of the implicit ternary that is behind the dor:
> >
> > defined($foo) ? $foo : $bar
> > $foo orelse $bar
> >
> >Best,
> >Tobias
> +1
> Carl Friedberg

If I may, +1 from me also. For hamming, "ore" ain't terrible.

Brett

>
>

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native