Re: how about just juxtaposing? (Re: Sane "+" string concat proposal)
On Wed, Apr 25, 2001 at 12:36:33AM -0500, David L. Nicol wrote:
>
> Ah.. I knew I'd find the thread in here somewhere.
>
> The problems go away if you allow white space to signify.
>
>
> > [...] Consider
> >
> > print "Foo"
> > foo("bar");
> >
> > Did the author forget a semi-colon, or did they intend to concatinate
> > there? Also, consider this...
> they forgot a semicolon. A spaceless juxtaposed concat would look like
>
> print "Foo"foo("bar");
Ick, please no. One of the things I like about Perl, as opposed to
Java say, is that a newline is almost never considered a statement
terminator. In Java (and probably a bunch of other languages), to
write a long string you need to do the equivalent of...
$foo = 'some stuff \
some more stuff \
and more stuff';
That or a bunch of concatinations. In Perl we don't have this problem
(we also have here-docs YAY!) This is very common in any code that
involves alot of embedded text (such as SQL or HTML).
The solution to the lack of a semi-colon dangerously stretches this
nice feature of Perl.
It also looks like a smashed jumble. The eye trips on all those
quotes without any distinguishing whitespace or word breaks.
print "Foo"foo('bar');
could easily be confused at first glance with
print "Foo foo('bar')";
the eye has alot of trouble distinguishing the two.
I think Nat said it best in his "What's Up With Those Python Fucks
Anyway" talk. Whitespace (or lack thereof) as syntax misses the key
point about whitespace in code. Its used to disambiguate and clarify.
Hijacking it as syntax means it can no longer be used as such.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Ooops, fatal mutation in the test script.
Re: Sane "+" string concat proposal
Lightning flashed, thunder crashed and Bart Lateur <[EMAIL PROTECTED]> whis pered: | I'm really beginning to like | | $string3 = $string1 _ $string2; | | The underscore indeed "connects" the two strings. This still breaks because _ is a valid word character. Again, we have to make the language be white space sensitive. -spp
Re: Sane "+" string concat proposal
On Wed, 25 Apr 2001 08:25:40 -0400, Stephen P. Potter wrote: >| I'm really beginning to like >| >| $string3 = $string1 _ $string2; >| >| The underscore indeed "connects" the two strings. > >This still breaks because _ is a valid word character. So are "cmp", "and", "lt", and the proposed "cat" and "cc". Having operators consisting of word characters doesn't really seem to be any problem, except that you may not attach them at the end of a variable's name. -- Bart.
Re: how about just juxtaposing? (Re: Sane "+" string concat proposal)
Ah.. I knew I'd find the thread in here somewhere.
The problems go away if you allow white space to signify.
> [...] Consider
>
> print "Foo"
> foo("bar");
>
> Did the author forget a semi-colon, or did they intend to concatinate
> there? Also, consider this...
they forgot a semicolon. A spaceless juxtaposed concat would look like
print "Foo"foo("bar");
and we insist that indirect objects have a space in them. And introduce
"" "" for when you absolutely positively don't want to write an expression
with C.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Henrik's keyboard has nice letters like 'æ', 'ø' and 'å'
Re: Sane "+" string concat proposal
On Wed, 25 Apr 2001 00:37:53 +0100, Simon Cozens wrote: >>$string3 = $string1 . $string2; >>$string3 = "$string1" + "$string2"; > >That's now *five* characters required to perform a very common operation. > >Rather than one. I'm really beginning to like $string3 = $string1 _ $string2; The underscore indeed "connects" the two strings. But: as somebody else wrote: why on earth do we need to reserve the dot for OO? Why do we have to be compatible with everybody else in the world? Because we're not, anyway. Recently, there was a question about polymorphism in Perl. This person did not understand that it is possible that you can use the same method for two different classes, without them having a common superclass. It's perfectly possible in Perl (because method resolving actually is a form of symbolic dereferencing... heheh...), but most definitely not in most other OO languages. So, perl is different anyway. What does one tiny extra superficial difference of notation FGS make any difference. I think backward compatibility with Perl5 is far more important, than having the *appearance* of doing the same as other OO languages. -- Bart.
Re: Sane "+" string concat proposal
On Tue, Apr 24, 2001 at 11:42:00AM -0700, Nathan Wiger wrote: > THESE ARE NOT THE SAME TIRED ARGUMENTS! Ooh, different tired arguments! >$string3 = $string1 . $string2; >$string3 = "$string1" + "$string2"; That's now *five* characters required to perform a very common operation. Rather than one. I remain unconvinced. -- Remember: amateurs built the Ark; _professionals_ built the Titantic.
Re: Sane "+" string concat proposal
At 03:38 PM 4/24/2001 -0700, Nathan Wiger wrote: >"Stephen P. Potter" wrote: > > > > You still haven't given a good explanation of > > > > $a += sub(); # is it a string or a number? > > > > Does your plan mean that we can no longer have subs that are context > > dependent? > >No, Schwern asked me this same thing off list, here's what I said: > >One possibility: > >"$a" += foo(); Okay, I've been ignoring this more or less up until now, but... Can we *please* not do this? The "magic if stringified" trick will either shoot the optimizer (if we need to tell at runtime if something's string or non-string) or make my head explode trying to make the parser handle it in anything resembling an elegant way. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Sane "+" string concat proposal
"Stephen P. Potter" wrote: > > You still haven't given a good explanation of > > $a += sub(); # is it a string or a number? > > Does your plan mean that we can no longer have subs that are context > dependent? No, Schwern asked me this same thing off list, here's what I said: One possibility: "$a" += foo(); And for the multi-function version I'd say: $result = join " ", func1(), func2(); I don't see a solution for that with the C<"" +> proposal, so this is one issue. Any ideas? --- Summarizing, here are the pros/cons of this approach. Please let me know if I've left any out: Pros - Similar syntax to other HLL's (like .-deref) - Semantically separate string concat and numeric addition maintained - Most functionality maintained Cons - Lose some important . stuff, like with functions - The C<"" +> concept actually changes precedence of + in certain circumstances, which is weird - Parsing C<"" +> as an "op" just ain't that easy Anyways, I'm not sure of what the fate of this concept is going to be, and I'm not going to try and fight for it per se. Truthfully, I'd rather we keep -> and . as-is. I rather like them that way. However, if Larry decides that .-deref is happening, then this is at least one alternative of several to ponder, if for no other reason than it bridges Perl to other HLL's with a syntax/semantics that mostly works. -Nate
Re: Sane "+" string concat proposal
> | Under what I originally posted: > | > |$a += "$b";# string > |$a += $b; # numeric > > You still haven't given a good explanation of > > $a += sub();# is it a string or a number? The quotes don't work. Anything but the most basic statement introduces way more ambiguity than we should be comfortable with. And the idea that <" +> should be interpreted by the parser as an op, well, doesn't work. At all.
Re: Sane "+" string concat proposal
Lightning flashed, thunder crashed and Nathan Wiger <[EMAIL PROTECTED]> whisper ed: | Michael G Schwern wrote: | > | > Oh, not to seed the clouds or anything, but what about "+=" and ".="? | > Any proposal will have to deal with those. | | Under what I originally posted: | |$a += "$b";# string |$a += $b; # numeric You still haven't given a good explanation of $a += sub(); # is it a string or a number? Does your plan mean that we can no longer have subs that are context dependent? -spp
Re: Sane "+" string concat proposal
Michael G Schwern wrote: > > Oh, not to seed the clouds or anything, but what about "+=" and ".="? > Any proposal will have to deal with those. Under what I originally posted: $a += "$b";# string $a += $b; # numeric Seems easy enough... -Nate
Re: how about just juxtaposing? (Re: Sane "+" string concat proposal)
> This is going to make finding syntax errors a bit difficult, as many
> will simply become concatination operators. Consider
>
> print "Foo"
> foo("bar");
>
> Did the author forget a semi-colon, or did they intend to concatinate
> there? Also, consider this...
*sigh*. Ok, how about: '++'?
Ed
Re: Sane "+" string concat proposal
> The only reason you'd have to use the op form of a string concat is when > you have to add stuff in that isn't evaluated inside quotes, like funcs. That doesn't make sense. Your proposal was to cause quotes to force concat context, but here you say the op is only useful when evaluating stuff outside of quotes. Umm.
Re: Sane "+" string concat proposal
Lightning flashed, thunder crashed and Casey West <[EMAIL PROTECTED]> whispere d: | I would consider thinking about the bigger problem of: | | $string = foo() [something here] bar(); In either case, quoting the operands isn't going to work. $string = "foo()" + "bar()"; And, my one argument still stands, I get really tired of <'>foo<'>. That's four extra keystrokes just so we can change . to + under this plan. No thanks. -spp
Re: Sane "+" string concat proposal
"Stephen P. Potter" wrote: > > | In Perl 6, you would do this like so: > | > |$string3 = "$string1" + "$string2"; > > Once you go this route, you've pretty much destroyed the usefulness of > having a concat operator. It is far less typing to do > >$string3 = "$string1$string2"; Agreed. The point wasn't to get rid of that usage by any means, but rather to propose an alternative to "." since that will likely get gobbled up as a replacement for ->. The only reason you'd have to use the op form of a string concat is when you have to add stuff in that isn't evaluated inside quotes, like funcs. -Nate
Re: how about just juxtaposing? (Re: Sane "+" string concat proposal)
On Tue, Apr 24, 2001 at 08:42:10PM +0100, Michael G Schwern wrote:
: On Tue, Apr 24, 2001 at 02:32:39PM -0500, Jarkko Hietaniemi wrote:
: > Has the road of just putting things next to each other been extensively
: > tried? It works for Awk... "juxtapose", the Famous Invisible Perl
: > Operator.
: >
: > Perl 5 Perl 6
: >
: > $a = $b . $c; $a = $b $c; # or $b$c
: > $a = "foo".$c; $a = "foo" $c; # or "foo"$c
: > $a = foo . $c; $a = foo$c; # foo $c wouldn't work...
: > $a = $c . foo; $a = ${c}foo# (if foo is a function)
: > $a = foo() . $c;$a = foo() $c;
: > $a = $c . foo();$a = $c foo();
: > $a = $b->c . $d;$a = $b->c $d; # or $b->c$d;
:
: This is going to make finding syntax errors a bit difficult, as many
: will simply become concatination operators. Consider
:
: print "Foo"
: foo("bar");
:
: Did the author forget a semi-colon, or did they intend to concatinate
: there? Also, consider this...
Or, did they intend to concatinate 'print' and "Foo" in void context?
--
Casey West
Re: Sane "+" string concat proposal
On Tue, Apr 24, 2001 at 08:32:09PM +0100, Michael G Schwern wrote: : On Tue, Apr 24, 2001 at 12:23:24PM -0700, Austin Hastings wrote: : > 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 : : If we go this route, we may as well just use 'cc'. Much less typing : (no chording), less confusing, analagous to 'eq' and : 'gt'. I like 'cc' for that very reason. String operators should look the same, imho. -- Casey West
Re: how about just juxtaposing? (Re: Sane "+" string concat proposal)
On Tue, Apr 24, 2001 at 02:32:39PM -0500, Jarkko Hietaniemi wrote:
> Has the road of just putting things next to each other been extensively
> tried? It works for Awk... "juxtapose", the Famous Invisible Perl
> Operator.
>
> Perl 5 Perl 6
>
> $a = $b . $c; $a = $b $c; # or $b$c
> $a = "foo".$c; $a = "foo" $c; # or "foo"$c
> $a = foo . $c; $a = foo$c; # foo $c wouldn't work...
> $a = $c . foo; $a = ${c}foo# (if foo is a function)
> $a = foo() . $c;$a = foo() $c;
> $a = $c . foo();$a = $c foo();
> $a = $b->c . $d;$a = $b->c $d; # or $b->c$d;
This is going to make finding syntax errors a bit difficult, as many
will simply become concatination operators. Consider
print "Foo"
foo("bar");
Did the author forget a semi-colon, or did they intend to concatinate
there? Also, consider this...
print foo "bar";
Is that 'print foo("bar");' or 'print foo()."bar";' in Perl 5?
> I can see that the indirect objects can be painful
That's ok, just kill indirect objects. Ooop, I'll be leaving before
Nathan finishes loading his gun. ;)
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Hey Schwern! honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk!
Re: Sane "+" string concat proposal
From: "Austin Hastings" <[EMAIL PROTECTED]> > Perl 5Perl 6 > - > $name = "This" . "that"; $name = "This" "+" "that"; $name = "+" "+" "+" "+"; # uh???
how about just juxtaposing? (Re: Sane "+" string concat proposal)
I think the magical "+" isn't going to work.
Has the road of just putting things next to each other been extensively
tried? It works for Awk... "juxtapose", the Famous Invisible Perl
Operator.
Perl 5 Perl 6
$a = $b . $c; $a = $b $c; # or $b$c
$a = "foo".$c; $a = "foo" $c; # or "foo"$c
$a = foo . $c; $a = foo$c; # foo $c wouldn't work...
$a = $c . foo; $a = ${c}foo# (if foo is a function)
$a = foo() . $c;$a = foo() $c;
$a = $c . foo();$a = $c foo();
$a = $b->c . $d;$a = $b->c $d; # or $b->c$d;
I can see that the indirect objects can be painful
my $fh = open(...);
print $fh $blah;
but maybe we can spread magic thickly enough on filehandles so that
"concat to a filehandle" means output...
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: Sane "+" string concat proposal
On Tue, Apr 24, 2001 at 12:23:24PM -0700, Austin Hastings wrote: > 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 If we go this route, we may as well just use 'cc'. Much less typing (no chording), less confusing, analagous to 'eq' and 'gt'. > Perl 5Perl 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($<); All those quotes make my eyes bleed. Oh, not to seed the clouds or anything, but what about "+=" and ".="? Any proposal will have to deal with those. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Do you have a map? Because I keep getting lost in your armpits.
Re: Sane "+" string concat proposal
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 "", not " in a literal context". (Of course, someone
with more mojo than me may be able to convince folks that any qquoted
is sufficient, but ...)
>Perl 5Perl 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 5Perl 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 <
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 5Perl 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
Re: Sane "+" string concat proposal
On Tue, Apr 24, 2001 at 03:09:18PM -0400, Stephen P. Potter wrote:
: Lightning flashed, thunder crashed and Nathan Wiger <[EMAIL PROTECTED]> whisper
: ed:
: | 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";
:
: Once you go this route, you've pretty much destroyed the usefulness of
: having a concat operator. It is far less typing to do
:
:$string3 = "$string1$string2";
I would consider thinking about the bigger problem of:
$string = foo() [something here] bar();
Of course, if we choose to remove the concat operator all together
we're left:
$string = join '', foo(), bar();
I could live with that if I had to, but only if I had to.
: I've seen someone say something about concating a large list of scalars.
: Can you imagine:
:
: $longstring = "$short" + "$another" + "$andathird" + "$andafourth" +
: "$onemore" + "$okanother" +"$wowlots"
:
: Personally, my fingers got really tired of having to use the shift key for
: all the quotes, the $, and the +. Of course, I'd normally just write that
: as
:
: $longstring = join('', $short, $another, ... , $wowlots);
I would do that for this example anyhow.
--
Casey West
Re: Sane "+" string concat proposal
Nathan Wiger wrote: > string concatenation would be acheived by the > *combination* of "" and +. >$string3 = "$string1" + "$string2"; > Here's the key: The quotes are REQUIRED. If you left them > off, you'd get numeric addition. There is no magic type > inference. That, imho, is bending way too far in the wrong direction, just for the sake of having a "+" operator that seems to DWIM on both strings and numbers. By that logic, we should dispense with cmp, eq, lt, etc. and replace them with "$a" <=> "$b" "$a" == "$b" "$a" < "$b" etc. There really is no inherent benefit in having "+" mean concat in addition to, uh, addition, and it seems to be causing an undue amount of consternation. Certainly "+" is no more intuitive than "##" or "cc" or "cat". I also don't like the special status accorded the the left operand in your proposal. Seems unecessarily capricious and restricting. -- John Porter It's a sky-blue sky The satellites are out tonight let x = x
Re: Sane "+" string concat proposal
Lightning flashed, thunder crashed and Nathan Wiger <[EMAIL PROTECTED]> whisper
ed:
| 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";
Once you go this route, you've pretty much destroyed the usefulness of
having a concat operator. It is far less typing to do
$string3 = "$string1$string2";
I've seen someone say something about concating a large list of scalars.
Can you imagine:
$longstring = "$short" + "$another" + "$andathird" + "$andafourth" +
"$onemore" + "$okanother" +"$wowlots"
Personally, my fingers got really tired of having to use the shift key for
all the quotes, the $, and the +. Of course, I'd normally just write that
as
$longstring = join('', $short, $another, ... , $wowlots);
-spp
Re: Sane "+" string concat proposal
On Tue, Apr 24, 2001 at 11:42:00AM -0700, Nathan Wiger wrote: >Perl 5Perl 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. Your fourth example disturbs me. You change the precedence of the same operator based on context. That's just weird. Do we do that anywhere else? Oh, and you need to relax your "Always" a bit. "string" + $foo # string concat $foo + "string" # string concat Quotes around $foo shouldn't be necessary. As an aside, I wish we could do something like this with our comparators too. (Isn't that one of Damian's RFCs?) Although I get the feeling that this will cause more headaches. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Sane "+" string concat proposal
On Tue, Apr 24, 2001 at 11:53:49AM -0700, Mark Koopman wrote: : >Perl 5Perl 6 : >- : >print "Next is " . $i + 1;print "Next is " + $i + 1; : : : this is the root of the problemPerl 5 version is easy to : understand, Perl 6 version is still ambiguous It is important to explain that if either side of the '+' operator is in string context, it is interpreted as concat. These would all have string context: Perl5 Perl6 --- --- print "Next is " . $i + 1; print "Next is " + $i + 1; print 1 . $two; print 1 . "$two"; print 1 + 2 . $three; print 1 + 2 + "$three"; I think that another area of confusion might be the precidence model, which was not detailed. For example: [cwest@stupid cwest]$ perl -le'$i=2;print "Next is " . $i + 2' 2 [cwest@stupid cwest]$ perl -le'$i=2;print "Next is " . ( $i + 2 )' Next is 4 I would prescribe it to be the following, just like Perl5 is now: Perl5 Perl6 --- --- print "Next is " . ($i + 1);print "Next is " + ($i + 1); print 1 . $two; print 1 . "$two"; print (1 + 2) . $three; print (1 + 2) + "$three"; Numeric context wins. I am not opposed to this idea, I see it to be quite easy to understand, even without explicit parens, though they help. -- Casey West
Re: Sane "+" string concat proposal
On Tue, Apr 24, 2001 at 11:53:49AM -0700, Mark Koopman wrote: > >Perl 5Perl 6 > >- > >print "Next is " . $i + 1;print "Next is " + $i + 1; > > > this is the root of the problemPerl 5 version is easy to > understand, Perl 6 version is still ambiguous The Perl 5 version is also ambiguous as you didn't catch the precidence problem I noted eariler. ;) -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One ...and that, children, is how to clean and load a .38 revolver. Questions?
Re: Sane "+" string concat proposal
> 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. So, what would this do? $user_pass = (getpwuid($<))[0] + (getpwuid($<))[1]; Your operator is still ambiguous, since you probably want a concat, but have no place for the quotes. The convention needs to consider more than just variables.
Re: Sane "+" string concat proposal
Seems servicable. Doesn't exactly make me jump up and down, though.
A few nits...
On Tue, Apr 24, 2001 at 11:42:00AM -0700, Nathan Wiger wrote:
> 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 5Perl 6
>-
>print "Next is " . $i + 1;print "Next is " + $i + 1;
Two problems. First, the Perl 5 example is equivalent to:
print +("Next is " . $i) + 1;
and I don't think that's what you ment. I think you ment...
print "Next is " . ($i + 1);
Which brings up a problem. '"$foo" + $number' is numeric addition. So
shouldn't '"Next is " + ($i + 1)' be numeric as well since one of the
sides is unquoted? Probably not what you wanted.
This problem will happen with any complex expression which you can't
easily put quotes around.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
If you are only one year old, and this is the first time you have ever seen a
burger, your related neurons will gather into a new "hamburger" group. But I
bet you are not that young and already know what a burger is.
--Alex Chiu, Immortality Guy
Re: Sane "+" string concat proposal
>Perl 5Perl 6 >- >print "Next is " . $i + 1;print "Next is " + $i + 1; this is the root of the problemPerl 5 version is easy to understand, Perl 6 version is still ambiguous
Sane "+" string concat proposal
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 5Perl 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.
