Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Thoughts on some new operators for perl (6 or 7)

by BigLug (Chaplain)
on Mar 10, 2004 at 05:34 UTC ( [id://335364]=perlmeditation: print w/replies, xml ) Need Help??

I have a few things I'd like to see in perl 6 (or 7). (They may already be in development, I don't read as much apocolyptic literature as I probably should.)

Consider this code:

my $highest = 0; my $lowest = 1_000_000_000; foreach (@list_of_int) { $highest = $_ if $_ > $highest; $lowest = $_ if $_ < $lowest; # was $highest - see update }
Now I'd like to get rid of the '= $_ if $_ >' as it's annoyingly long winded. In the spirit of ||= ('or equals'), let me suggest =>> become 'equals the greater' and =<< become 'equals the lesser'. So now we have:
my $highest = 0; my $lowest; # undef foreach (@list_of_int) { $highest =>> $_; $lowest =<< $_; }
(I'd use '=>' but that would be confusing to perl5ers.)

There'd also be string equivelents:

my $highest = ''; my $lowest; # undef foreach (@list_of_string) { $highest eg $_; $lowest el $_; }
Note that my =<< and el operators would consider anything defined to be less than 'undef' which is why the my declarations for $lowest are undef. This means we don't have to guess a value that is higher than the lowest value when initialising.

Thoughts? Comments? Ridicule?

Update: Fixed typo pointed out by NetWallah. Added a pile of semi-colons.

"Get real! This is a discussion group, not a helpdesk. You post something, we discuss its implications. If the discussion happens to answer a question you've asked, that's incidental." -- in clpm

Replies are listed 'Best First'.
Re: Thoughts on some new operators for perl (6 or 7)
by Abigail-II (Bishop) on Mar 10, 2004 at 09:51 UTC
    A couple of things:
    • Lobbying for operators is best done at the appropriate perl6 language list(s). That's where the perl6 action is, and that's where doubts like They may already be in development can be answered quickly.
    • The task seems to be too minor to warrant two new operators.
    • If you do this often, you ought to be using generalized functions like min and max, or even reduce.
    • I don't know whether perl6 will have here documents, but in perl5, =<< would be ambiguous.
    • =>> and =<< are not in the spirit of ||=. In the latter, the implied operator is first, the assignment later. With your suggested operators, this is reversed.
    • Perl6 will allow you to define your own operators.


      I don't know whether perl6 will have here documents, but in perl5, =<< would be ambiguous.

      I'm sure I read somewhere that Perl 6 *will* have here documents. They were said to require quotes around the terminator specification and automatically remove equal indenting.

      But... I can't find the reference anywhere, so it could just have been a dream.

      Juerd # { site => '', plp_site => '', do_not_use => 'spamtrap' }

Re: Thoughts on some new operators for perl (6 or 7)
by kvale (Monsignor) on Mar 10, 2004 at 06:11 UTC
    I think that in principle there is nothing wrong with these operators. But getting them included would be a hard sell, because a module solution is already available and easy to use:
    use List::Util qw(max maxstr min minstr); my $highest = max @numlist; my $highstr = maxstr @strlist; my $lowest = min @numlist; my $lowstr = minstr @strlist;


Re: Thoughts on some new operators for perl (6 or 7)
by Juerd (Abbot) on Mar 10, 2004 at 07:14 UTC

    I think it is very hard to read and for something that nobody does very often. (It'd make Perl like PHP, but with non-alphanumeric operators...) Introducing at least 8 new operators just to save a few characters is not worth it for such a rare occasion.

    ||= and //= are not comparing operators like > and <. They aren't comparison operators. They're normal binary operators that happen to short circuit. Syntactically they work like +, so they deserve a mutating variant, just like the other binary operators:

    || ||= && &&= ^^ ^^= // //= + += ~ ~= - -= * *= / /= % %= +& +&= ~& ~&= +| +|= ~| ~|= +^ +^= ~^ ~^= +< +<= ~< ~<= +> +>= ~> ~>= x x=
    I wouldn't be surprised to see . get a .=.

    Juerd # { site => '', plp_site => '', do_not_use => 'spamtrap' }

      .= is already in Perl5. But the period is a completely different operator in Perl6, and .= doesn't make sense for its new purpose (it's for obj.method calls, just like many other OO langs).

      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

        .= doesn't make sense for its new purpose

        If you can't imagine a function for it, it automatically does not make sense?

        It could very well become a mutator for objects. As $foo += 5 equals $foo = $foo + 5, $foo .= lc could equal $foo = $ Especially for @foo.sort and @foo.=sort, this would be great to have.

        I've been wanting mutating and non-mutating versions of builtins for a while now, and this seems to me a good way to do it.

        See also Re: Re: What should be returned in scalar context?.

        Does it make sense now?

        Juerd # { site => '', plp_site => '', do_not_use => 'spamtrap' }

Re: Thoughts on some new operators for perl (6 or 7)
by etcshadow (Priest) on Mar 10, 2004 at 07:02 UTC
    Really, the operator that I want is ''= or some such. This would be the equivalent of ||=, but for comparison against eq '' rather than boolean true-falseness.

    I understand that there is a patch out there for a //= operator that does the same thing for undef, and I think that's really cool... but I'd still like to see the empty-string defaulting operator, as well.

    ------------ :Wq Not an editor command: Wq

      I'd guess it's not useful enough for the core language, but I might be guessing wrong. However, should it not be implemented, then with Perl 6 you can still choose to do so yourself:

      sub infix:'' ($foo, $bar) { $foo eq '' ? $bar : $foo } sub infix:''= ($foo is rw, $bar) { $foo = $foo '' $bar }
      Likewise, the OP can implement their new operators if they really want it.

      Juerd # { site => '', plp_site => '', do_not_use => 'spamtrap' }

        The '//' and '//=' (defined or) operators aren't in the core because they tend to be ambigious with an empty regex (like in split //, $str). They should be in 5.10, though.

        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

Re: Thoughts on some new operators for perl (6 or 7)
by TimToady (Parson) on Mar 10, 2004 at 22:26 UTC
    You shouldn't necessarily assume you have to loop at all. Perl 6 also lets you take a junctional approach:
    $lowest = one(@list_of_int) <= all(@list_of_int); $highest = one(@list_of_int) >= all(@list_of_int); $lowest = one(@list_of_int) le all(@list_of_string); $highest = one(@list_of_int) ge all(@list_of_string);
    Or something like that...
      one(@list_of_int) <= all(@list_of_int)

      Shouldn't that be true if the lowest value is a dupe and false if not?

      Now four years later I think what the op wanted is best written:

      my $lowest = [min] @list_of_int;
        Yes, though we didn't have reduce operators back then, nor did we have infix min and max that would allow you to say
        for @list { $min min= $_; $max max= $_; }
        But [minmax] @list might be what the OP really wants.

        And to answer tye's question, min and max are multiply dispatched, so it depends on the types of each pair of arguments. Non-comparable values probably produce an error, but any ordered type will work if used consistently.

        (And my grandparent response was probably bogus, since junctions are really only for doing boolean logic, not pulling out actual values. But given that I was very sick four years ago, I'm not surprised...)

        I assume that one() isn't the same as any().

        So is "min" numeric or alpha?

        - tye        

Re: Thoughts on some new operators for perl (6 or 7)
by NetWallah (Canon) on Mar 10, 2004 at 05:41 UTC
    You may want to fix the typo: Your line should read:

    $lowest = $_ if $_ < $highest

    $lowest = $_ if $_ < $lowest;
    You also need a semicolon on the previous line.

    Other than that - yes - this seems somewhat useful, but I'd probably not remember the syntax when I needed to use it, so I'm ambivalent about promoting it. Thanks for sharing the idea, though.

Re: Thoughts on some new operators for perl (6 or 7)
by tachyon (Chancellor) on Mar 10, 2004 at 13:09 UTC
    my $issue =<<'THIS_IS_WHY'; You cant use =<< It is already used (at least in p5) as you can see What might be nice is more OO syntax like my $min = @list.min my $max = @list.max But you can already get almost that from [cpan://List::Util] THIS_IS_WHY print $issue




      In Perl 6 that would be @array.min, as arrays themselves are objects. Note that @list is misleading as it is an ARRAY not a LIST. In English they may be similar, but in code it is very important to make the distinction.

      Juerd # { site => '', plp_site => '', do_not_use => 'spamtrap' }


        The @ defines precisely what is meant.



        So, you're implying that it will be illegal to use 'list' as an array name in Perl6? What on earth are you talking about?

        Also, he was backslashing the @ because \@list.min was in an interpolating heredoc.

Re: Thoughts on some new operators for perl (6 or 7)
by Roy Johnson (Monsignor) on Mar 10, 2004 at 18:24 UTC
    It seems to me that if it were pursued, you'd want a general conditional assignment operator. I chose ?= for notation because I don't think it conflicts with any existing syntax, and it has some intuitive appeal to me, because of the resemblance to, e.g., ||=. Follow it with a comparison operator and the value to compare. If the comparison is true, do the assignment:
    # syntax lvalue ?= op value; # ex: $lowest = $_ if $lowest > $_; $lowest ?= > $_; # ex: $highest = substr($_, 10, 5) if $highest lt substr($_, 10, 5) $highest ?= lt substr($_, 10, 5); # ex: $foo ||= $bar, using the generalized ?= operator $foo ?= || $bar;
    The last isn't quite equivalent to $foo ||= $bar, for cases where $foo and $bar are different values of false. ||= would do the assignment; ?= would not.

    Unary tests could work, if Perl understands that unary operators operate on the lvalue, and I think in that case that ! should be combinable with other ops, since we already have $a ||= $b to denote $a = $b if !$a:

    # ex: $foo = $default if !defined($foo) $foo ?= !defined $default; # ex: $foo{'bar'} = $default if exists($foo{'bar'}) # That is, we're resetting the value, but not creating it $foo{'bar'} ?= exists $default;
    That's not going to win any converts from //= notation, and there's not much clamor for exists-based-defaulting, but it did seem a logical extension.

    Update: extending a little further, we could make unary operators into mutators by making the value optional. If no value is given, the result of the (unary) operation is assigned back to the lvalue:

    # $foo = uc($foo) $foo ?= uc; # even do arrays! @arr ?= reverse;
    Operators that can be unary or binary present a syntactic problem. What is meant by
    # $foo = 5 if -$foo? # $foo = $foo - 5 if $foo - 5? $foo ?= - 5;
    ? I think assuming binary operators in those cases make sense, while in the unambiguous case of no argument, you could negate a value with minimal typing:
    $foo{$bar}{$baz} ?= -;

    The PerlMonk tr/// Advocate
Re: Thoughts on some new operators for perl (6 or 7)
by bl0rf (Pilgrim) on Mar 10, 2004 at 23:21 UTC
    I have not used a lower/higher comparison assignment often enough to think that it should be included in the core language, I'm sure others use it as seldom as I do.

Re: Thoughts on some new operators for perl (6 or 7)
by wolfi (Scribe) on Mar 22, 2004 at 08:49 UTC

    well, i just gotta say, that i do question the backward-compatibility of the symbols, you've chosen... BUT i definitely like the concept of using some "most" and "least" operator. :-)

    i didn't really follow you completely -> if you meant the "equal to the least" could equal undefined or not. If you did - my only thought is that it should equal the last defined value instead, because it would seem while reading any file, array, etc - the last operation of it would always be to return undefined (if i understand that whole process correctly). That would make that operator just a duplicate of testing for undef.

    but anyways - i like your ideas :-)

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://335364]
Approved by kvale
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (1)
As of 2024-04-16 00:11 GMT
Find Nodes?
    Voting Booth?

    No recent polls found