Some of the objections have gone by, but what if you reverse the
quotes?
Make operator-in-quotes be a string operator (hell, make that true for
the other ops, too)
Perl 5 Perl 6
--------------- ---------------
-> .
+ +
. "+"
eq "=" or eq
gt ">" or gt
Special rule: the operator is "<literal doublequote><plus><literal
doublequote>", not "<plus> in a literal context". (Of course, someone
with more mojo than me may be able to convince folks that any qquoted
<op> is sufficient, but ...)
> Perl 5 Perl 6
> ----------------------------- ----------------------------
> $res = $var + $var2; $res = $var + $var2;
> $name = "This" . "that"; $name = "This" + "that";
> $name = "This" . $that; $name = "This" + "$that";
> print "Next is " . $i + 1; print "Next is " + $i + 1;
> $me = $name . getpwuid($<); $me = "$name" + getpwuid($<);
Perl 5 Perl 6
----------------------------- ----------------------------
$res = $var + $var2; $res = $var + $var2;
$name = "This" . "that"; $name = "This" "+" "that";
$name = "This" . $that; $name = "This" "+" "$that";
print "Next is " . $i + 1; print "Next is " "+" $i + 1;
$me = $name . getpwuid($<); $me = $name "+" getpwuid($<);
It has the advantage of separating the need to distinguish the operator
out to the operator, so the "func1() . func2()" arguments are
eliminated, and it's just as hideous as anything else. Plus, it's
intuitive and easy to type, even for those poor benighted folks who
don't have $LOCALE or xmodmap or MSFT Multiple language support.
(And admit it, "All string operators must be surrounded by string
quotes" is newby-friendly, even if it does make my skin crawl...)
Frankly, I like the "cc" operator idea better.
(Although maybe as a unary operator, "cc" could still be defined as
returning a sub generated by feeding its arguments to the
system-provided 'C' compiler...)
$hi_sub = cc <<END_CODE
#include <stdio.h>
int foo(void)
{
printf("Hello, world.\n");
}
END_CODE
ORIGINAL MESSAGE
--- Nathan Wiger <[EMAIL PROTECTED]> wrote:
> THESE ARE NOT THE SAME TIRED ARGUMENTS! If you're on p5p, you're
> probably already rolling your eyes. However, I searched p5p all the
> way
> back to 1997 and could not find this proposal anywhere. Even though
> it
> looks similar to the standard "Java + concat overload" stuff, it is
> not,
> so please try to keep an open mind.
>
> Everyone agrees that keeping string and numeric ops semantically
> separate is a Good Thing. As Dave nicely explained, this allows us to
> twist our scalars into strings or numbers based on the operators,
> instead of the other way around. This allows a single scalar type.
> This
> is not something we want to lose.
>
> Under this proposal, string concatenation would be acheived by the
> *combination* of "" and +. So, in Perl 5 you would have something
> like
> this:
>
> $string3 = $string1 . $string2;
>
> In Perl 6, you would do this like so:
>
> $string3 = "$string1" + "$string2";
>
> Here's the key: The quotes are REQUIRED. 100%. Always. If you left
> them
> off, you'd get numeric addition. Always. There is no magic type
> inference.
>
> Think of this like using $ and [] to get an array element. You can't
> just say 'array[1]' or '$array' and expect to get the right thing.
> Rather, you have to combine the two. Same here, you have to combine
> ""
> and +.
>
> The win here with Perl is that having $prefixes actually allows us to
> expand variables in "" still. No other HLL can do that. As such,
> other
> languages have to overload their operators based on type. In Perl, we
> can maintain the semantics of a separate string concat by requiring
> quotes. This is hardly a far cry from current; in fact, it's quite
> logical (since "" is already string context) and very close
> syntactically to other HLL's.
>
> So, here's a little table:
>
> Perl 5 Perl 6
> --------------- ---------------
> -> .
> + +
> . "" and +
>
> You get a Java/Python/etc syntax while retaining the semantics of
> separate string and numeric ops.
>
> More Details
> ------------
> Ok, if you're still reading, cool. Let's get down to the
> nitty-gritty.
> Here are some more examples of code:
>
> Perl 5 Perl 6
> ----------------------------- ----------------------------
> $res = $var + $var2; $res = $var + $var2;
> $name = "This" . "that"; $name = "This" + "that";
> $name = "This" . $that; $name = "This" + "$that";
> print "Next is " . $i + 1; print "Next is " + $i + 1;
> $me = $name . getpwuid($<); $me = "$name" + getpwuid($<);
>
> That last one is important. Notice that the "" on the $name means
> that
> the next + becomes a string concat. The getpwuid call is then
> concat'ed
> onto that. If, instead, you wrote:
>
> $me = $name + getpwuid($<);
>
> You would get numeric addition. Always. In this way, you maintain a
> reliable semantic separation of string concat and numeric addition,
> while gaining a syntax that is similar to other HLL's. Having "$var"
> expand $var is the reason this is possible.
>
> Anyways, what do you think? (Please try to resist knee-jerk Java
> reactions :).
>
> -Nate
>
> P.S. I've got many more examples, but didn't want to flood the list
> with
> a massive proposal. I'm pretty sure all the bases are covered, but am
> interested in potential gotcha's...
>
> P.P.S. I'm also not some Java newbie who's complaining about "." and
> "eq", so don't even go there.
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
