By logical conclusion, this will mean that they are no longer valid in variable names

From the looks of the discussion right now this is not true. You will need to disambiguate that the _ is not part of a variable name with whitespace. So: my $baz = $foo_bar.$bar_foo becomes my $baz = $foo_bar _ $bar_foo. The whitespace on the left side of the _ is not optional.

update: s/around/on the left side of/

I was hoping someone would have some good news, but I still don't see the point in changing Perl's syntax for the sake of (cheesy) dot syntax for method calls. I will assume that the powers that be that are working on Perl6 have good reasons, but as I stated, it just seems like an attempt to make Perl more friendly to java(script) programmers. From what I gleaned from the article (which obviously had some holes) underscores are replacing periods for concatenating and periods are replacing the arrow operator. So, again, to what end? Change and innovation is (almost) always good, but needless change???

matt

If we want to make Perl more attractive for people from OTHER languages, we need to compromise. Many other languages use the obj.method syntax, so why shouldn't Perl? The reason Perl doesn't is because we never had objects until recently, and we've had string concatenation for a long long time.

_____________________________________________________
Jeff[japhy]Pinyan: Perl, regex, and perl hacker.
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

The dot operator

I used to think that replacing -> with . sucked big time, until I read Piers Cawley's article about Perl 6. Now I have learned to stop worrying and love the dot. It's sort of like Visual Basic's with block. Instead of

   $self->{foo} = $self->bar ? 10 : $self->rat * 10;
[download]

one instead writes

   $.foo = .bar ? 10 : .rat * 10;
[download]

Although IIRC, that should be ?? and :: for the ternary conditional operator. Such considerations aside, the succinctness of the dot approach far outweighs the arrow approach (which, it should be remembered, was itself a vast improvement over the apostrophe operator). Your surely agree with me when I say

   $->foo = ->bar ? 10 : ->rat * 10;
[download]

looks... odd. That's reason enough for me to go with the dot approach.

The underscore operator

I do think that requiring whitespace around the underscore operator is a bit of a design wart caused by exhaustion of the ASCII character set. Which means that there's not a lot you can do about it.

In a Unicode environment, I imagine it would be preferable to define a specific operator that doesn't require whitespace disambiguation. I think a small ring character like on a Swedish A would be pretty cool. But if you're not Unicode pure then I guess you're out of luck.

--

g r i n d e r

There's quite a bit that's changing with respect to array/hash refs and changing how they are accessed fits into that. It could be done withtout changing -> to . but with the other reasons, it fits. From Exegesis 2:

        Access through...       Perl 5          Perl 6
        =================       ======          ======
        Scalar variable         $foo            $foo
        Array variable          $foo[$n]        @foo[$n]
        Hash variable           $foo{$k}        %foo{$k}
        Array reference         $foo->[$n]      $foo[$n] (or $foo.[$n]
+)
        Hash reference          $foo->{$k}      $foo{$k} (or $foo.{$k}
+)
        Code reference          $foo->(@a)      $foo(@a) (or $foo.(@a)
+)
        Array slice             @foo[@ns]       @foo[@ns]
        Hash slice              @foo{@ks}       %foo{@ks}
[download]

3) It really doesn't need to be used for derefrencing, just for OO.

2) Just about every other language that supports OO uses dot notation (could be all, but I'm covering my bases). It takes away a reason not to use Perl.

3)Perl is going to have much better OO functionality. It's not just going to be something that's hacked on top of what's already there (like now).

4) It's one less character

And you probably still don't like it. Maybe because I haven't been around that language that long, but I personally like the change. In a year or so, I'd bet it's no longer an issue.

Rich

I agree. This is a change made for the sake of consistency. I'm not a big fan of the underscore, but I can see the point. Overloading '+', like Java does in its String class wouldn't work -- not with magical DWIM scalars. (No snide remarks about Java's consistency here, either :).

The dot operator isn't just for OO -- it'll be used to access properties and attributes as well. Sure, you could argue that it's syntactic sugar for lvalue subs, but I like sugar, in measured doses. It'll be used commonly, and one character is shorter than two. It'll probably be easier to read, too, because the dot is small.

I'll personally have a bit of trouble with the sigils becoming part of the variable name, instead of indicating what to expect. Then again, consider how many new programmers make context errors like @array[1] = localtime;.

It's change, yeah, but it's not for the sake of change. It's for the sake of consistency, Perlishness in general, and the principle that Perl should Just Make Sense. I'll miss the dot concatenation operator, but I'm willing to spend the 30 seconds it takes to learn a few new operators. In the long run, this is a good change.

Overloading '+', like Java does in its String class wouldn't work -- not with magical DWIM scalars.

Personally, I was more disappointed with using '_' instead of '+' than I was with using '.' instead of '->'. (FWIW, I don't understand WYM w.r.t. DWIM scalars.)

Personally I found the variable notation to be one of the more 'exotic' things about Perl. I rather like exotic things. It was neat that the variable character told Perl how to treat what you were extracting, rather than telling Perl about the container that held it. However I agree that it can get a bit hairy when you get to code like @{$thing[$c]}[$b].

I personally think Perl is losing a little of it's syntactic mystique, but from the sound of it we are getting a more magical engine, so it should still be fun. And ultimately, that's why I've stuck with Perl despite all the times I've tried to wean myself onto Eiffel, Java, etc.

____________________
Jeremy
I didn't believe in evil until I dated it.

Not to be dismissive, but: it's just syntax, you'll get used to it. Think of the people who look at Perl and see nothing but line noise -- they're not used to identifying types by sigils (@, %, &), regular expression notation, etc. What do we tell them? "It's just syntax, you'll get used to it." And we're right :-)

Chris
M-x auto-bs-mode

Yes, but Perl has a very good syntax (so far as I'm concerned), so why change it? The question is not whether I'll get used to it (if they change it, I'll have no choice), it's why is it really necessary? To appease people who don't use the language? Change for change's sake is not a good thing...

matt

____________________
Jeremy
I didn't believe in evil until I dated it.