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;
| [reply] [Watch: Dir/Any] [d/l] |
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.
Abigail | [reply] [Watch: Dir/Any] |
|
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.
| [reply] [Watch: Dir/Any] |
|
But... I can't find the reference anywhere, so it could just have been a dream.
Nope. Not a dream. That's from Exegesis 7 (search the page for "heredoc").
| [reply] [Watch: Dir/Any] |
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 .=.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
.= 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 = $foo.lc. 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?
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
|
|
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... | [reply] [Watch: Dir/Any] [d/l] |
|
my $lowest = [min] @list_of_int;
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
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...) | [reply] [Watch: Dir/Any] [d/l] [select] |
|
| [reply] [Watch: Dir/Any] |
Re: Thoughts on some new operators for perl (6 or 7)
by NetWallah (Canon) on Mar 10, 2004 at 05:41 UTC
|
$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. | [reply] [Watch: Dir/Any] [d/l] |
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
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
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.
| [reply] [Watch: Dir/Any] [d/l] |
|
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
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
| [reply] [Watch: Dir/Any] [d/l] |
|
\@list.min
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.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
| [reply] [Watch: Dir/Any] [d/l] |
|
|
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.
| [reply] [Watch: Dir/Any] [d/l] |
|
|
|
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
| [reply] [Watch: Dir/Any] [d/l] [select] |
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.
| [reply] [Watch: Dir/Any] |
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 :-)
| [reply] [Watch: Dir/Any] |