Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

operators '|||' and '&&&' #15220

Closed
p5pRT opened this issue Mar 10, 2016 · 18 comments
Closed

operators '|||' and '&&&' #15220

p5pRT opened this issue Mar 10, 2016 · 18 comments

Comments

@p5pRT
Copy link

p5pRT commented Mar 10, 2016

Migrated from rt.perl.org#127684 (status was 'rejected')

Searchable as RT127684$

@p5pRT
Copy link
Author

p5pRT commented Mar 10, 2016

From Ulrich.Windl@rz.uni-regensburg.de

Hi!

While writing a program for perl-5.10, I wondered whether the is an AND-equivalent for '//' for a closure like
sub {
  my $hi = $header_i{(shift)} ??? return $hi;
  die;
  };

Where '???' is the operator that doesn't exist.
Thus I wondered why the perl gurus didn't choose '|||' instead of '//'; then '&&&' would be just the natural thing for the AND-variant.
Did I overlook something that would have prevented use of those operators?

Regards,
Ulrich

@p5pRT
Copy link
Author

p5pRT commented Mar 10, 2016

From @Tux

On Thu, 10 Mar 2016 04​:10​:02 -0800, "Ulrich Windl" (via RT)
<perlbug-followup@​perl.org> wrote​:

Hi!

While writing a program for perl-5.10, I wondered whether the is an
AND-equivalent for '//' for a closure like

sub {
my $hi = $header_i{(shift)} ??? return $hi;
die;
};

When the defined-or was introduced, there was​: the "err" keyword, which
was implemented as a weak keyword.

Later it has been removed.

Where '???' is the operator that doesn't exist.

Currently there is none. One of the reasons for removal was the fact
that "err" could clash with existing function names (as field tests
proved). Other names were suggested, but none where seen as acceptable
enough to warrant the potential clash.

Thus I wondered why the perl gurus didn't choose '|||' instead of
'//'; then '&&&' would be just the natural thing for the AND-variant.
Did I overlook something that would have prevented use of those
operators?

Personally, I'd love to see the return of "err" (or whatever name would
be chosen), but I am not holding my breath till that happens.

Regards,
Ulrich

--
H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/
using perl5.00307 .. 5.23 porting perl5 on HP-UX, AIX, and openSUSE
http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/
http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

@p5pRT
Copy link
Author

p5pRT commented Mar 10, 2016

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Mar 10, 2016

From @leonerd

On Thu, 10 Mar 2016 04​:10​:02 -0800
"Ulrich Windl" (via RT) <perlbug-followup@​perl.org> wrote​:

then '&&&' would be just the natural thing for the AND-variant.
Did I overlook something that would have prevented use of those
operators?

There's no need for a "defined-and" operator in Perl, because there is
no undefined value that is true. The regular "and" operators are fine
in this circumstance.

--
Paul "LeoNerd" Evans

leonerd@​leonerd.org.uk
http​://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS

@p5pRT
Copy link
Author

p5pRT commented Mar 10, 2016

From @kentfredric

On 11 March 2016 at 01​:50, Paul "LeoNerd" Evans <leonerd@​leonerd.org.uk> wrote​:

then '&&&' would be just the natural thing for the AND-variant.
Did I overlook something that would have prevented use of those
operators?

There's no need for a "defined-and" operator in Perl, because there is
no undefined value that is true. The regular "and" operators are fine
in this circumstance.

I'm going to have to know what interpretation of code is expected from
defined-and before I Understand this claim.

Both my interpretations don't hold the same behaviour as &&

              0&#8203;: defined\-and\(0\) =     "true"\, defined\-and\(1\) =        "0"\, andand =        "0"
   empty\-string&#8203;: defined\-and\(0\) =     "true"\, defined\-and\(1\) =         ""\, andand =         ""
         truthy&#8203;: defined\-and\(0\) =     "true"\, defined\-and\(1\) =   "truthy"\, andand =     "true"
          undef&#8203;: defined\-and\(0\) =      undef\, defined\-and\(1\) =      undef\, andand =      undef

--
Kent

KENTNL - https://metacpan.org/author/KENTNL

@p5pRT
Copy link
Author

p5pRT commented Mar 10, 2016

From @kentfredric

dand.pl

@p5pRT
Copy link
Author

p5pRT commented Mar 10, 2016

From Ulrich.Windl@rz.uni-regensburg.de

"Paul LeoNerd Evans via RT" <perlbug-followup@​perl.org> schrieb am 10.03.2016
um 13​:51 in Nachricht <rt-4.0.18-31775-1457614269-1401.127684-94-0@​perl.org>​:
On Thu, 10 Mar 2016 04​:10​:02 -0800
"Ulrich Windl" (via RT) <perlbug-followup@​perl.org> wrote​:

then '&&&' would be just the natural thing for the AND-variant.
Did I overlook something that would have prevented use of those
operators?

There's no need for a "defined-and" operator in Perl, because there is
no undefined value that is true. The regular "and" operators are fine
in this circumstance.

"a // b" is the shortcut for "defined(a) or b" ("defined(a) ? a : b"), and "a &&& b" would be a shortcut for "defined(a) and b". Did I miss the obvious?

--
Paul "LeoNerd" Evans

leonerd@​leonerd.org.uk
http​://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS

@p5pRT
Copy link
Author

p5pRT commented Mar 10, 2016

From zefram@fysh.org

Ulrich Windl wrote​:

"a // b" is the shortcut for "defined(a) or b"

$ perl -lwe 'print +(3 // 4)'
3
$ perl -lwe 'print +(defined(3) or 4)'
1

defined(a) evaluates to 1 if a is defined, not to a.

("defined(a) ? a : b")

This is a more accurate explanation of //.

and "a &&& b" would be a shortcut for "defined(a) and b".

I presume it would be defined(a) ? b : a. It's not brilliantly useful.
// is good for situations where you're using undef as a null value in
a, and you want to apply a default if it's null. It requires only a
single undef-as-null slot to be useful. defined-and, however spelled,
would require a coincidence of two undef-as-distinguished-value slots
to be useful​: a and the output. The operation that it computes is not
one that naturally arises from the undef-as-null arrangement. So I do
not think it warrants a new punctuation operator.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Mar 10, 2016

From Ulrich.Windl@rz.uni-regensburg.de

"Zefram via RT" <perlbug-followup@​perl.org> schrieb am 10.03.2016 um 15​:49 in
Nachricht <rt-4.0.18-25787-1457621351-1313.127684-94-0@​perl.org>​:
Ulrich Windl wrote​:
"a // b" is the shortcut for "defined(a) or b"

$ perl -lwe 'print +(3 // 4)'
3
$ perl -lwe 'print +(defined(3) or 4)'
1

You are right! I wasn't fully awake, sorry!

defined(a) evaluates to 1 if a is defined, not to a.

("defined(a) ? a : b")

This is a more accurate explanation of //.

and "a &&& b" would be a shortcut for "defined(a) and b".

I presume it would be defined(a) ? b : a. It's not brilliantly useful.

It would be useful in the original context. I tired to make this a one-liner​:
  my $index_by_name = sub {
  my $hi = $header_i{(shift)};

  die unless (defined($hi));
  return $hi;
  };

// is good for situations where you're using undef as a null value in
a, and you want to apply a default if it's null. It requires only a
single undef-as-null slot to be useful. defined-and, however spelled,
would require a coincidence of two undef-as-distinguished-value slots
to be useful​: a and the output. The operation that it computes is not
one that naturally arises from the undef-as-null arrangement. So I do
not think it warrants a new punctuation operator.

OK.

Ulrich

@p5pRT
Copy link
Author

p5pRT commented Mar 10, 2016

From zefram@fysh.org

Ulrich Windl wrote​:

It would be useful in the original context. I tired to make this a one-liner​:
my $index_by_name = sub {
my $hi = $header_i{(shift)};

   die unless \(defined\($hi\)\);
   return $hi;

};

  my $index_by_name = sub { $header_i{(shift)} // die };

This is a defined-or situation, not defined-and.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Mar 10, 2016

From Ulrich.Windl@rz.uni-regensburg.de

"Zefram via RT" <perlbug-followup@​perl.org> schrieb am 10.03.2016 um 16​:11 in
Nachricht <rt-4.0.18-31775-1457622680-1028.127684-94-0@​perl.org>​:
Ulrich Windl wrote​:
It would be useful in the original context. I tired to make this a one-liner​:
my $index_by_name = sub {
my $hi = $header_i{(shift)};

   die unless \(defined\($hi\)\);
   return $hi;

};

my $index\_by\_name = sub \{ $header\_i\{\(shift\)\} // die \};

This is a defined-or situation, not defined-and.

Thanks, I forgot "If no "return" is found and if the last statement is an expression, its value is returned." (wisdom from "man perlsub")

-zefram

@p5pRT
Copy link
Author

p5pRT commented Mar 14, 2016

From @Abigail

On Thu, Mar 10, 2016 at 04​:25​:17PM +0100, Ulrich Windl wrote​:

"Zefram via RT" <perlbug-followup@​perl.org> schrieb am 10.03.2016 um 16​:11 in
Nachricht <rt-4.0.18-31775-1457622680-1028.127684-94-0@​perl.org>​:
Ulrich Windl wrote​:
It would be useful in the original context. I tired to make this a one-liner​:
my $index_by_name = sub {
my $hi = $header_i{(shift)};

   die unless \(defined\($hi\)\);
   return $hi;

};

my $index\_by\_name = sub \{ $header\_i\{\(shift\)\} // die \};

This is a defined-or situation, not defined-and.

Thanks, I forgot "If no "return" is found and if the last statement is an expression, its value is returned." (wisdom from "man perlsub")

You don't even need that; it works with an explicit return as well​:

  sub {return $header_i {+shift} // die}

Abigail

@p5pRT
Copy link
Author

p5pRT commented Mar 14, 2016

From @Abigail

On Thu, Mar 10, 2016 at 04​:10​:02AM -0800, Ulrich Windl wrote​:

# New Ticket Created by "Ulrich Windl"
# Please include the string​: [perl #127684]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=127684 >

Hi!

While writing a program for perl-5.10, I wondered whether the is an AND-equivalent for '//' for a closure like
sub {
my $hi = $header_i{(shift)} ??? return $hi;
die;
};

Where '???' is the operator that doesn't exist.
Thus I wondered why the perl gurus didn't choose '|||' instead of '//'; then '&&&' would be just the natural thing for the AND-variant.
Did I overlook something that would have prevented use of those operators?

Perl has wasted years [1] of bike-shedding over the spelling of the defined-or
operator [2], before actually implementing it -- let's not redo that.

[1] '|||' was floating around on IRC at least as early as 1997. '//' came
  to live in 5.10, which was released near the end of 2007.
[2] I think the name was settled by Larry invoking rule 1, but I may be
  mistaken.

Abigail

@p5pRT
Copy link
Author

p5pRT commented Mar 14, 2016

From @bulk88

On Thu Mar 10 04​:10​:00 2016, Ulrich.Windl@​rz.uni-regensburg.de wrote​:

Hi!

While writing a program for perl-5.10, I wondered whether the is an
AND-equivalent for '//' for a closure like
sub {
my $hi = $header_i{(shift)} ??? return $hi;
die;
};

Where '???' is the operator that doesn't exist.

??? looks like unicode replacement characters in an IDE. Very bad choice for an operator. Atleast with C's ? there will very soon be a "​:" to the right of it to verify it isn't replacement character. "???" can be bad UTF conversion of source code.

--
bulk88 ~ bulk88 at hotmail.com

@p5pRT
Copy link
Author

p5pRT commented Jun 20, 2016

From @ap

* Ulrich Windl <perlbug-followup@​perl.org> [2016-03-10 13​:15]​:

While writing a program for perl-5.10, I wondered whether the is an
AND-equivalent for '//' for a closure like
sub {
my $hi = $header_i{(shift)} ??? return $hi;
die;
};

Where '???' is the operator that doesn't exist.

First, an aside​: under strict vars, this would never work, no matter how
such an operator were spelled, because declarations do not take effect
until after the end of the statement – the `return $hi` part in that
statement will always be a compile-time error.

As for what you asked about, you can achieve this already, by using the
existing defined-or to convert undef to an empty list, which allows you
to use a loop as a conditional​:

  return $_ for $header_i{(shift)} // ();

(Depending on circumstances you might also use a grep or map instead. Or
a full block loop, which allows you to name the value.)

I’ve used this idiom a fair amount.

Thus I wondered why the perl gurus didn't choose '|||' instead of
'//'; then '&&&' would be just the natural thing for the AND-variant.

Who knows. The symmetry argument almost certainly didn’t come up though,
because the AND version is needed much less often than the OR version.

Judging by the fact that //() has become an idiom for me, a defined-and
operator is clearly not a useless idea – evidently I would have used it
plenty, even if less than defined-or.

Did I overlook something that would have prevented use of those
operators?

At least &&& is already sometimes valid syntax in contexts where this
new interpretation for it would be applicable, so it’s more ambiguous
than // was.

* H.Merijn Brand <h.m.brand@​xs4all.nl> [2016-03-10 13​:20]​:

When the defined-or was introduced, there was​: the "err" keyword,
which was implemented as a weak keyword.

That was a low-precedence version of defined-or, so it’s irrelevant to
the OP who was talking about defined-and.

* Paul "LeoNerd" Evans <leonerd@​leonerd.org.uk> [2016-03-10 13​:55]​:

There's no need for a "defined-and" operator in Perl, because there is
no undefined value that is true. The regular "and" operators are fine
in this circumstance.

Incorrect. No undefined value is true, but that doesn’t mean every
defined value is true. For false defined values, the regular `and`
operators yield different results than defined-and would.

* Zefram <zefram@​fysh.org> [2016-03-10 15​:50]​:

It's not brilliantly useful. // is good for situations where you're
using undef as a null value in a, and you want to apply a default if
it's null. It requires only a single undef-as-null slot to be useful.
defined-and, however spelled, would require a coincidence of two
undef-as-distinguished-value slots to be useful​: a and the output.
The operation that it computes is not one that naturally arises from
the undef-as-null arrangement. So I do not think it warrants a new
punctuation operator.

It’s useful enough that shell has *only* defined-and, and no defined-or.
Shell calls it “alternate value expansion”, which ought to give a clear
indication of the use cases it’s good for.

* bulk88 via RT <perlbug-followup@​perl.org> [2016-03-14 19​:15]​:

??? looks like unicode replacement characters in an IDE. Very bad
choice for an operator.

This seems like it must be humour, in which case it is so bone dry that
it leaves me unable to decide whether or not it is.

Anyway, this ticket should probably be closed.

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

@p5pRT
Copy link
Author

p5pRT commented Jun 20, 2016

@cpansprout - Status changed from 'open' to 'rejected'

@p5pRT p5pRT closed this as completed Jun 20, 2016
@p5pRT
Copy link
Author

p5pRT commented Jun 21, 2016

From @xsawyerx

On 06/20/2016 07​:31 AM, Aristotle Pagaltzis wrote​:

[...]

??? looks like unicode replacement characters in an IDE. Very bad
choice for an operator.
This seems like it must be humour, in which case it is so bone dry that
it leaves me unable to decide whether or not it is.

I fail to see how this comment adds *anything* to the conversation.
Please refrain from such "observations" in the future.

Anyway, this ticket should probably be closed.

This seems right to me. Does anyone object to closing this?

@p5pRT
Copy link
Author

p5pRT commented Jun 24, 2016

From Ulrich.Windl@rz.uni-regensburg.de

"Sawyer X via RT" <perlbug-followup@​perl.org> schrieb am 21.06.2016 um 16​:16 in
Nachricht <rt-4.0.18-16653-1466518574-1536.127684-94-0@​perl.org>​:

On 06/20/2016 07​:31 AM, Aristotle Pagaltzis wrote​:

[...]

??? looks like unicode replacement characters in an IDE. Very bad
choice for an operator.
This seems like it must be humour, in which case it is so bone dry that
it leaves me unable to decide whether or not it is.

I fail to see how this comment adds *anything* to the conversation.
Please refrain from such "observations" in the future.

Anyway, this ticket should probably be closed.

This seems right to me. Does anyone object to closing this?

No ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant