Larry Wall wrote:
>
> The . is just syntax. Do you mean something semantic by ".-based"?
No, but I think "just syntax" is a little misleading. I do agree that we
"well, Perl 5 did it this way" is not a sufficient design decision at
this point. However, if you changed Perl's syntax too radically you
would almost certainly lose programmers. You drop the $'s, change -> to
., do this/that/etc and pretty soon it looks like Java, which people
like myself really dislike. One of the reasons I program in Perl as my
primary language is *because of* the syntax.
> I don't care about commutative either, but what you are proposing is to
> throw away a particularly useful feature of Perl, which is its
> autoconversion between numbers and strings. That we're not going
> to lose. This implies that string operators must stay distinct
> from numeric operators.
I don't think that this is necessarily true (more below).
> Doesn't ~ look like a piece of string to you? :-)
>
> I think it kind of looks like a stitch.
It looks like a bitwise op to me, personally. I've never seen it used
anywhere as a string concat. Again, that's not to say it can't be in
Perl 6, but it would be a real oddity.
> Then how do you concatenate a number?
Here's something I was thinking about at lunch:
$concated_number = "$number" + "$other_number";
$numerical_add = $number + $other_number;
Why not require "" in the case when you want to forcible concat a number
as a string? Most people write:
$string = "$number$other_number";
Already anyways. You would only have to disambiguate if one of the args
was not a string. So here would be some equivalents:
Perl 5 Perl 6
------------------------- ------------------------
"This" . "that" "This" + "that"
$this . "that" $this + "that"
$maybe_a_num . $that "$maybe_a_num" + $that
$i++ $i++
$i + 1 $i + 1
I know this isn't the first time something like this has been suggested.
And the problem isn't necessarily with the above, but with stuff like
this:
die "Nope" unless ($i == 0); # eq 0 ??
But I'd argue all you have to do is use "":
die "Nope" unless ($i == "0"); # str eq
die "Nope" unless ("$i" == 0); # same
die "Nope" unless ($i == 0); # num ==
Unlike Java and other languages, Perl has an advantage with $'s: You can
use quotes to disambiguate, since "$var" will still expand $var (unlike
"var"). This opens up a whole bunch of interesting alternatives.
> Me either. But then you propose to break one of the most endearing
> features of Perl 5.
No, not by any means. Sorry if I wasn't clear.
> There are many people who would prefer . to ->, if for no other reason
> than it's cleaner looking and is one less character to type. The fact
> that it's become the industry standard for method call syntax is also
> a point in its favor.
I do agree with that, but by this logic then we should look seriously
into using "+" for string concat. Otherwise, all we're doing is trading
one oddity for another. Sure, "." now means object deref, but why (says
the JavaDrone) do I use "~" for string concat? That's weird.
Plus, you're now requiring all the Perl hackers to relearn two major
tenets of Perl: "->" and ".".
Again, if this is going to be done, IMO it needs to be done wholesale
otherwise it will be detrimental to language.
> : I know we're just brainstorming still,
>
> Well, maybe we are, at that. But I feel as though I've been in design
> mode for a while now. That is, any brainstorming I'm doing at this
> point is merely to feel my way into the ramifications of making some of
> the hard-nosed decisions that have to be made.
All I meant was that just because an email comes out that says "I think
we should rename @foo to ^bar" doesn't mean it's set in stone...yet.
> I think Perl is still suboptimal as C glue, and we can improve it. If
> it becomes better VM glue at the same time, all the better. But I fail
> to see how . notation can be much of a political issue, unless people
> choose to turn it into one.
No, I don't think it's a political issue at all. But syntax is a big
part of a language. You could argue that this code:
using System;
void public static Main () {
Console.Print("Hello, World!\n");
}
Is "just syntax" too, but that doesn't mean it's easy or fun. Perl is
both, and syntax is a huge chunk of that.
> : The latter space is already populated w/ Java and C#,
> : and Sun and MS have a little bit of marketing cash.
>
> And because they have better marketing we should therefore concede in
> the technical sphere? I don't follow.
No, but if Perl looks 95% like Java or C#, my prediction would be it
will lose. If you throw out everything from the tens of previous years
of Perl, then you cause a whole bunch of JAPH's to relearn lots. And
then, these people might be prompted to say "Hey, if I have to relearn
all this, let me check out some alternatives." At which point you lose
people to Java or C# or other similar languages.
This is something to watch out for, not something that should decide
Perl 6's design for paranoia's sake. I know that I am not the only one
that loves Perl first and foremost for its syntax. Change too much and
you're bound to drive some people away. Especially if these changes are
inconsistent with other languages.
My conclusion: I say we do ". and +" or neither. We could make it DWIM
if we try, I'm sure of it.
-Nate
