#Perl 5:

if ( $i > 0 && $i < 5 ) {

if ( $string eq 'foo' or $string eq 'bar' ) {

use List::Util;
my $n = reduce { $a * $b } @A;

$foo->bar;

#Perl 6:

if 0 < $i < 5 {

if $string eq 'foo' | 'bar' {

my $n = [*] @A;

$foo.bar;
[download]

There will be less typing:

Indeed. See also Perl6 burns 18% fewer calories.

Look forward to: //. Oh, man am I looking forward to that. In fact, once we can standardise our perl development on 5.10, I'm going to be taking huge advantage of that operator.

A little concerned about: ?: becoming ??::. Maybe I use this operator more than I should. But that said, it's still something that so many other languages have that it'll be difficult to make the transition.

That said, I'm sure that within the first 6 months after perl6 is "officially" available, someone will have written a filter to transpose ?: to ??:: in your code automatically. ;-)

Look forward to: //.

Amen! Usually when I encounter || in code, if it's not actually a bug, I still have to slow down long enough to verify that.

Cheers,
Ovid

New address of my CGI Course.

Yup. It's funny how all the counter-arguments seem to have vanished into the mist.

That said, I'm sure that within the first 6 months after perl6 is "officially" available, someone will have written a filter to transpose ?: to ??:: in your code automatically. ;-)

Except that it won't be a filter, but a grammar modification. And although some fear that much power for the inherent risks of introducing icompatible dialects, I'm looking forward what we could actually see...

What is your concern about the ?? :: operator? I like the new fat forms, because they're easier to spot and are now somewhat grouped with && and ||.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

By the way, we just changed ??:: to ??!! for various reasons, the most important of which is to avoid visual confusion with :: as a name separator. But it also has a nice correspondence with the relationship of unary ? and ! operators. (Plus it discourages people from defining their own !! infix operator, which was deemed to be confusing in various ways.)

Yea, I used to dread the idea of using ~ for concat. However, Perl6 does have string interp. In addition, Perl6's string interp. will be even more powerfull than 5's. So, we may find ourselves using ~ less often than we might think.

Ted Young

($$<<$$=>$$<=>$$<=$$>>$$) always returns 1. :-)

Also, ~ will be used to introduce string context too. So it may take a while, but first or later we will all get used to associate it to strings...

There are still many ways to avoid needing the tilde. There will be normal interpolation as in Perl 5 ("$foo$bar") but new is interpolation of closures ("int($baz) = { int($baz) }", resulting in something like int(5.6) = 5). There is also sprintf, now know as "as" ([$foo, $bar].as("%s%s") or maybe also "%s%s".as($foo, $bar), which may not make sense at first, but will make sense when written as as "%s%s": $foo, $bar).

Personally I don't find ~ hard to type, and I absolutely love its place in Perl 6, not only as the string concatenation operator, but also as the string context operator and the stringy semi-meta operator in bit operators.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Yikes, I didn't know they were changing so many basic things! I'm officially scared of Perl 6 now. That tilde just seems extremely unintuitive. I'm worried Perl 6 might be going the Python route and trying too hard to be different from every other language.

I am ignorant, and only know Perl, so I shouldn't have said anything else about other languages. Sorry.

Walking the road to enlightenment... I found a penguin and a camel on the way.....
Fancy a yourname@perl.me.uk? Just ask!!!

Is -> for derefencing also getting the axe? Or only for method calls? Seems sensible to keep $hashref->{'key'}, no?

I think ¥ as infix zip is excessively cute.  And maybe useful.

On the other hand, [...] reduction, ==>/<== pipes, and »...« hyper are really cool and definitely useful.

However Perl6 will need it for another purpose, i.e. for "pointy subs", which may be a better choice especially from the huffmanization point of view. Also, do you imagine something like

$bar ->= nextitem;
[download]

or

@newstuff = map { ->method } @stuff;
[download]

?!?

Speaking of pointy subs and of their parameters, I find it to be quite interesting that the syntax resembles much that of my old faithful HP-28s pocket calculator (HP48*'s one should be practically identical), which happen to be an entirely coincidental fact, as Larry Wall himslef clarified in Re: Q: re C<< -> >>.

Also, my favourite one, which every other language doesn't use, ->, is getting binned...

lol, here is the worry for Perl. When you see someone makes definitive statement with full confidence, quite often you are facing one who is ignorant.

The guy seems have no idea that c use both -> and . depends on whether a struct or a struct pointer is involved.

for example:

[*] 1..100; # applies '*' to all list; so result is 100!
[//] @a; # first defined
[+] @b; # sum of all
[download]

Not operator, but very close - junctions are promising to be very convenient:

if $a eq "foo" | "bar" | "fluffy" {
  # do this stuff
}
[download]

my most expected favourite is meta-operator []

Is that just syntatic sugar for fold?

Yes and no. The basic definition of [op] in Perl 6 is syntactic rather than semantic, so it will do either foldl or foldr depending on the syntactic associativity of the operator in question. But the syntactic definition goes a little beyond that, insofar as it can be applied to context-dependent syntactic operators that have no fixed run-time meaning, such as [;] or [,]. Since the meanings of ; and , depend on syntactic context, so do the meanings of [;] and [,].

Furthermore, it can be applied to operators that are neither left nor right-associative, such as the various list-associative operators, which in Perl 6 includes the comparison operators. So you can write

    [<] @array
[download]

to mean

    @array[0] < @array[1] < @array[2] ...
[download]

which will tell you if the array is monotonically increasing without having to do strange semantic contortions to separate value from success (see Icon).

There will still be need for underlying foldl and foldr equivalents to force folding "against the grain", but for most purposes (including educational and visual), the [op] form is more accessible, I think.

For the same reason Perl 5 has '+'and '.': because of the extremely convenient auto-conversion of strings to numbers:

# in Perl 5
$i=10;         # could be $i="10";
$j=1;          # could be $j="1";
print $i + $j; # 11
print $i . $j; # 101
[download]

most languages (that I know) use the + for both

Yes, but other languages don't have Perl's notion of context. In Perl, the + operator supplies numeric context, but the concatenation operator supplies string context. The difference can be important.

  my $barcode_prefix = "25728"; 
  for my $b (@series) {
    my $chkd = checkdigit($barcode_prefix . $b);
  }
[download]

If you change the concatenation operator there to +, a completely different thing happens and the check digit comes out wrong. (And yes, I have written code that calculates barcode check digits in Perl5.)

In those languages you must do somthebg like int($a) + int($b) if you have read the numbers from a file, in Perl you can add them whitout telling them to be numbers first. It also means there must be a diffrent concat operator.

I'm not sure how it'd work what with Perl constantly auto-stringifying and auto-numberfying things. I'd think we need separate numeric-add and string-concatenate operators for the same reason we need separate == and eq.

That's an easy one...
1. '+' should be associative (like in mathematics).
2. Concatenation isn't associative.
3. Therefore, concatenations shouldn't be denoted by '+'.

Concatenation isn't associative.

This is, of course, completely wrong. Mathematically, the set of all strings over an alphabet forms a (associative) monoid under the concatenation operator.

Did you mean commutative?

blokhead

What I'd really like to see change, is not the shape of the operators ( . becomes ~, -> becomes . or nothing, & becomes +& or ~&, sub { becomes {,... ). It's the precedence of operators.

I understand that in perl6, comma had to have a higher precedence than assignment, for C compatibility. But is this the case with perl6 too? In perl6, the comma will not have its perl5 meaning in scalar context anymore, so couldn't we also raise the precedence of the comma, so that we can write @numbers = 12, 5, 4, 8, 9, 11; instead of @numbers = (12, 5, 4, 8, 9, 11);? Also, will concatenation finally have lower precedence than addition and subtraction? It's a bit annoying in perl5 that their precedence is equal, so you have to parenthisize print "2 + 5 = " . (2 + 5);.

Update 2006 Jun 12: Funnily, list assignment now has a low enough precedence in perl6 for this to work.

The design team certainly considered (at length) changing the precedence of comma with respect to assignment, but in the end, after weighing all the pros and cons, it seemed to us that cultural continuity and enforced visual encapsulation won out over the slight gain in convenience.

As for the relationship of concatenation and addition, when we had a choice between adding more precedence levels or unifying precedence levels, we had a slight bias towards unification, so anything remotely resembling addition or multiplication tended to end up at those precedence levels. This is one of those areas where you have to balance out the need for extra parens with the need to keep a complex precedence table in one's head, and in this case we (again) opted for the extra parens in order to keep the mental model simpler. It doesn't hurt the reader of your code to have to parenthesize a few things, and while Laziness is one of the chief virtues of a programmer, with Perl 6 we're trying to take into account the Laziness of the reader as well as the writer.

with Perl 6 we're trying to take into account the Laziness of the reader as well as the writer

Now I feel enthralled. (++)

Cheers, Sören

And once again the Cult of Simplicity At Any Cost rears its head...

We are, in fact, trying to make Perl 6 simpler and more regular and hence more easily learnable in various ways. If you look at all the operators carefully, you'll see a lot of that regularity built-in. However, we are not optimizing Perl primarily for learnability, but for expressiveness.

How hard it is to master a language has very little to do with how useful it is. We've said this many times before, and plan to continue to say it until it sinks in, but the important thing is not how simple your language is, but whether there is an impedance match between the problem space and the solution space. Your problem has a certain natural complexity that has to be reflected in the solution. If you artificially push complexity out of the core language and into the libraries, all you're doing is forcing the user to learn a complex set of libraries instead. And you have fewer guarantees that the various library interfaces will have been designed coherently.

That is not to say that the Worse is Better style of development doesn't work--it's been amazingly successful in the case of C and Unix and HTML, and you can even view Perl's current success that way. See CPAN.

However, just look at what happens with something like shell programming. Every command has its own ideas of how to parse its arguments, and as a whole they are much less learnable than they could be. Shell programming has always been a pain precisely because of this tendency to shuffle the complexity out of the core syntax. Misplaced complexity results in "induced complexity" in your solution, and that's like leaving your landing gear out while trying to fly supersonic. Or take Java. Please.

So occasionally you have to take a Better is Better design cycle to try to recapture some of that complexity into the core solution space. And sometimes you lose big when you try that, if the Worse is Better hordes manage to outcompete you anyway. But if the design is sufficiently advanced over the state of the art, and if you can stand to the popularity "hit" while you redesign, you eventually win back big. And even if you can't stand the "hit", you come up with a lot of really good ideas for other languages to steal. That's how Perl initially won out over shell programming. And that's what we're going for with Perl 6. We may fail to jump out of the pot, but we're not going to be boiled to death without at least trying to jump once.