Well, generally, I try to keep my mouth shut and stay out of these
kinds of things, but I'd really like to see some more discussion on
this one. So, ...
It's not a wacko idea, imho; in fact, it could also work quite well
with a "Stop-and-Copy" semispaces-type GC, if Dan elects to go with
somethi
Bart Lateur <[EMAIL PROTECTED]> writes:
> My vote is to ditch the concat operator altogether. Hey, we have
> interpolation!
> "$this$is$just$as$ugly$but$it$works"
How do you concatenate together a list of variables that's longer than one
line without using super-long lines? Going to the
Branden <[EMAIL PROTECTED]> writes:
> 1) Use $obj.method instead of $obj->method :
> The big question is: why fix what is not broken? Why introduce Javaisms
> and VBisms to our pretty C/C++-oid Perl? Why brake compatibility with
> Perl 5 code (and Perl 5 programmers) for a zero net gain?
$obj.m
This may or may not be related to Dave's post, but I just remembered
why I don't like a dual-natured +. I'm sorry if this was gone through
before.
Consider the following...
sub foo { $_[0] + $_[1] }
What do the following return?
foo(1,1); obviously 2
foo(
On Mon, Apr 23, 2001 at 11:31:18AM -0700, Larry Wall wrote:
> 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 fav
On 24 Apr 2001 00:29:23 -0700, Russ Allbery wrote:
>How do you concatenate together a list of variables that's longer than one
>line without using super-long lines? Going to the shell syntax of:
>
>PATH=/some/long:/bunch/of:/stuff
>PATH="${PATH}:/more/stuff"
>
>would really be a shame.
On Tue, 24 Apr 2001 10:49:18 +0100, Simon Cozens wrote:
>While that's true, concatenation is quite a common operation
>that I'd be really
>uncomfortable with it necessitating 4 keystrokes (" cat") instead of one.
Er, "~" is an extremely annoying character to type at many keyboards. It
may depen
> From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> > Make concatination be "$a cat $b". ("eq" and friends
> already provide
> > precedent for string operators being words rather than symbols.)
>
> While that's true, concatenation is quite a common operation
> (Introspection
> is cool. Run "perl
Larry Wall <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons writes:
>: >You really have to talk about overloading boolean context
>: >in general.
>:
>: Only if you are going to execute the result in the normal perl realm.
>: Consider using the perl parser to build a parse tree - e.g. one to
>: read
Dan Sugalski wrote:
> The one downside is that you'd have essentially your own private language.
> Whether this is a bad thing or not is a separate issue, of course.
IIUC, this ability is precisely what Larry was saying Perl6 would have.
--
John Porter
David M Lloyd <[EMAIL PROTECTED]> writes:
> On 24 Apr 2001, Russ Allbery wrote:
>> The switch from -> to . makes perfect sense from a C perspective if we're
>> turning objects into first-class entities rather than pointers; think
>> about a struct versus a pointer to a struct.
>>
>> -> makes you
On Tue, Apr 24, 2001 at 03:26:04PM +0200, Henrik Tougaard wrote:
> > From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> > On Tue, Apr 24, 2001 at 12:31:44PM +0200, Henrik Tougaard wrote:
> > > Please don't use the keypresscount as an argument.
> > Why not? We're making easy things easy, remember.
> B
On 24 Apr 2001, Russ Allbery wrote:
> David M Lloyd <[EMAIL PROTECTED]> writes:
>
> > What's wrong with using both? You could use -> if you're working with a
> > reference to an object, and you could use . if you're working with the
> > object itself.
>
> It seems relatively unlikely in the co
At 06:34 AM 4/24/2001 -0700, Russ Allbery wrote:
>David M Lloyd <[EMAIL PROTECTED]> writes:
> > On 24 Apr 2001, Russ Allbery wrote:
>
> >> The switch from -> to . makes perfect sense from a C perspective if we're
> >> turning objects into first-class entities rather than pointers; think
> >> about
On Tue, Apr 24, 2001 at 12:31:44PM +0200, Henrik Tougaard wrote:
> On my keyboard '~' is 3 keystrokes - and rather complicated ones
> at that:
Then maybe ~ isn't best.
> Please don't use the keypresscount as an argument.
Why not? We're making easy things easy, remember.
--
Rule 3: If the char
At 09:33 AM 4/24/2001 -0400, John Porter wrote:
>Dan Sugalski wrote:
> > The one downside is that you'd have essentially your own private language.
> > Whether this is a bad thing or not is a separate issue, of course.
>
>IIUC, this ability is precisely what Larry was saying Perl6 would have.
I a
David M Lloyd <[EMAIL PROTECTED]> writes:
> On 24 Apr 2001, Russ Allbery wrote:
>> It seems relatively unlikely in the course of normal Perl that you're
>> going to end up with very many references to objects.
> Well, right now in Perl, an object *is* a reference.
Precisely. So there's almost
On Tue, 24 Apr 2001 14:37:02 +0100, Simon Cozens wrote:
>Let's put it a different way - if we can find a short operator which
>is readily accessible on most people's keyboards, then that would
>score over a longer operator which is readily accessible on most
>people's keyboards. Maybe ~ isn't th
On Tue, Apr 24, 2001 at 08:38:58AM -0500, David M. Lloyd wrote:
> Well, right now in Perl, an object *is* a reference.
No. An object is a referent. Two blessed references can refer to the
same data; however, that's only one object.
--
teco < /dev/audio
- Ignatios Souvatzis
At 08:01 PM 4/23/2001 -0500, David L. Nicol wrote:
>Larry Wall wrote:
> >
> > David L. Nicol writes:
> > :
> > : [this parser switch thing]
> > : sounds a lot like an "exec" system call: there are some things
> > : which remain in effect (open file handles, current directory,
> > : environment) bu
On Tue, 24 Apr 2001, Simon Cozens wrote:
> On Tue, Apr 24, 2001 at 08:38:58AM -0500, David M. Lloyd wrote:
> > Well, right now in Perl, an object *is* a reference.
>
> No. An object is a referent. Two blessed references can refer to the
> same data; however, that's only one object.
Oops, that's
On Tue, Apr 24, 2001 at 12:29:23AM -0700, Russ Allbery wrote:
> How do you concatenate together a list of variables that's longer than one
> line without using super-long lines?
join '', $var1, $var2, $var3, ..., $varN;
TMTOWTDI, remember.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Simon Cozens wrote:
> Let's put it a different way - if we can find a short operator which
> is readily accessible on most people's keyboards, then that would
> score over a longer operator which is readily accessible on most
> people's keyboards. Maybe ~ isn't that operator. Maybe & is, or ^ or
On Mon, Apr 23, 2001 at 05:19:22PM -0700, Larry Wall wrote:
> At the moment I'm leaning toward ^ for concat, and ~ for xor. That
> will help with ^= not resembling =~, though ~= would still mean The
> Wrong Thing...
As has been mentioned by others, ^ has established meaning in other
programming
> From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> On Tue, Apr 24, 2001 at 12:31:44PM +0200, Henrik Tougaard wrote:
> > Please don't use the keypresscount as an argument.
>
> Why not? We're making easy things easy, remember.
>
Because your keyboard layout isnt mine! I have nice letters like
'æ',
At 02:55 AM 4/24/2001 -0400, John Porter wrote:
>Dan Sugalski wrote:
> > It wouldn't be all that tough to change this if you were so inclined--it'd
> > certainly be a simpler parser modification than some others that have been
> > proposed.
>
>Yes, I hadn't thought of that. Yay again.
The one do
On 24 Apr 2001, Russ Allbery wrote:
> Branden <[EMAIL PROTECTED]> writes:
>
> > 1) Use $obj.method instead of $obj->method :
>
> > The big question is: why fix what is not broken? Why introduce Javaisms
> > and VBisms to our pretty C/C++-oid Perl? Why brake compatibility with
> > Perl 5 code (a
I've updated http://www.sidhe.org/~dan/perl/gc.html (as well as html-izing
it. The text version's still there) for those who are curious.
Specifically the implementation section for reference tracking and the PMC
arena stuff's done.
If folks would care to look and comment, that'd be keen. Bet
Apologies all...I have the document, but I'm having trouble getting it out
of my computer. I don't have Internet access yet and my floppy drive is
refusing to read. I'll see if I can get the printer hooked up tonight,
print the thing out, retype it at work tomorrow, and send it in then.
Dave
Or, rather, I think we should have one. Naming the interpreter separate
from the language may help folks keep the various bits separate in their
minds. (It'll certainly help me be clearer when I talk about it)
Personally, I'm up for calling the interpreter "Parrot" unless someone has
an object
At 11:27 AM 24/04/2001 -0400, Dan Sugalski wrote:
>Or, rather, I think we should have one. Naming the interpreter separate
>from the language may help folks keep the various bits separate in their
>minds. (It'll certainly help me be clearer when I talk about it)
Actually, I think the language
At 12:35 PM 4/24/2001 -0300, Branden wrote:
>At 11:27 AM 24/04/2001 -0400, Dan Sugalski wrote:
>>Or, rather, I think we should have one. Naming the interpreter separate
>>from the language may help folks keep the various bits separate in their
>>minds. (It'll certainly help me be clearer when I
From: Russ Allbery [mailto:[EMAIL PROTECTED]]
> David M Lloyd <[EMAIL PROTECTED]> writes:
> > On 24 Apr 2001, Russ Allbery wrote:
> > >
> > > It seems relatively unlikely in the course of normal Perl
> > > that you're going to end up with very many references to
> > > objects.
> >
> > Well, right
On Tue, 24 Apr 2001, Graham Barr wrote:
> On Mon, Apr 23, 2001 at 05:19:22PM -0700, Larry Wall wrote:
>
> > At the moment I'm leaning toward ^ for concat, and ~ for xor. That
>
> I think that would lead to confusion too. In many languages ^ is
> xor and ~ is a bitwise invert. It is that way i
On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote:
> I think someone may have mentioned this already, but why not just say
> that if you want '.' to mean concatenation, you have to surround it on
> either side with white space? If there's no white space around it, then
> it is force
On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote:
:
: On Tue, 24 Apr 2001, Graham Barr wrote:
:
: > On Mon, Apr 23, 2001 at 05:19:22PM -0700, Larry Wall wrote:
: >
: > > At the moment I'm leaning toward ^ for concat, and ~ for xor. That
: >
: > I think that would lead to confusio
On Tue, 24 Apr 2001, Dan Sugalski wrote:
> Or, rather, I think we should have one. Naming the interpreter separate
> from the language may help folks keep the various bits separate in their
> minds. (It'll certainly help me be clearer when I talk about it)
>
> Personally, I'm up for calling the i
At 12:00 PM 4/24/2001 -0400, Dan Sugalski wrote:
>I've updated http://www.sidhe.org/~dan/perl/gc.html (as well as html-izing
>it. The text version's still there) for those who are curious.
>Specifically the implementation section for reference tracking and the PMC
>arena stuff's done.
Y'know,
On Tue, Apr 24, 2001 at 01:05:24PM -0700, Nathan Wiger wrote:
>$a = $b . $a;
>
> Under the above plan, maybe this is:
>
>$a ca $b;
>
> For "concat after"?
I'd rather it be called "pp" for prepend. :-)
It's good that we decided to let Larry design the language, otherwise
we'd be mired
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
On Tue, Apr 24, 2001 at 01:05:24PM -0700, Nathan Wiger wrote:
: Michael G Schwern wrote:
: >
: > cc and ce
: >
: > Perl 5 Perl 6
: > print "foo" . "bar";print "foo" cc "bar;
: > print 2 . 4;print 2 cc 4;
: >
> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
NW>$a = $b . $a;
NW> Under the above plan, maybe this is:
NW>$a ca $b;
substr( $a, 0, 0, $b ) ;
$a =~ s/^/$b/ ;
just my $.02 on this. i rarely use bare . for concat. as someone else
mentioned, it is usually o
~ looks like a string to me Larry sycophant that I am.
, also looks a little like a string. And is keyboard friendly.
Its doubtless naive to suggest it, but why not:
Perl 5 Perl 6
--- ---
-> .
+ +
. ~+
eq ~==
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 e
> 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
ou
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 e
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 = "
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 woul
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
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
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 li
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
On Tue, Apr 24, 2001 at 05:44:49PM +0100, Michael G Schwern wrote:
> On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote:
> > I think someone may have mentioned this already, but why not just say
> > that if you want '.' to mean concatenation, you have to surround it on
> > either side
> ok, well.. I've heard arguments for '+' (namely that its intuitive, other
> language compatible, etc...) so what are the arguments against it?
Well, it looks like I'm a little bit behind. Spend 15 minutes typing something,
and you get 7 messages in your mailbox on the exact topic that you had
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
> --- ---
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
On Tue, Apr 24, 2001 at 12:23:33PM -0700, Edward Peschko wrote:
> ok, well.. I've heard arguments for '+' (namely that its intuitive, other
> language compatible, etc...) so what are the arguments against it?
This one seems to have slipped by...
http://archive.develooper.com/perl6-language%40per
From: "Austin Hastings" <[EMAIL PROTECTED]>
> Perl 5Perl 6
> -
> $name = "This" . "that"; $name = "This" "+" "that";
$name = "+" "+" "+" "+"; # uh???
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;
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
>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
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.
Ok, time for me to shot down.
I've already voiced my views about trying to make addition and
concatination into a single operator in a typeless language
http://archive.develooper.com/perl6-language%40perl.org/msg06550.html
and I think its a losing proposition.
So here's something simple. Sort o
"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";
Ag
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 sti
Michael G Schwern wrote:
>
> On Tue, Apr 24, 2001 at 12:23:33PM -0700, Edward Peschko wrote:
> > ok, well.. I've heard arguments for '+' (namely that its intuitive, other
> > language compatible, etc...) so what are the arguments against it?
>
> This one seems to have slipped by...
> http://arch
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:
>
>
> 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 r
For those of us who came in late...I gather that -> is expected to be
replaced by '.', which means that we need to find something else for '.'.
Somehow, however, I missed out what the exact benefits are of this
replacement--I'm not saying that there *aren't* any, I just never saw the
message whe
On Tue, Apr 24, 2001 at 01:05:24PM -0700, Nathan Wiger wrote:
> While we're brainstorming a wish-list, here's something I've always
> wanted, a replacement for:
>
>$a = $b . $a;
I don't think there's any pressing need for this unless you can show a
common case where a prepend op would make t
Uri Guttman wrote:
>
> on the other hand, i use .= all the time and wouldn't like to lose
> it. schwern idea of ce doesn't work for me as only the op= stuff means
> assignment and ce would break that (e for = isn't visual enough).
I was just thinking, too bad that Larry's claiming the colon
curr
From: "Jonathan Scott Duff" <[EMAIL PROTECTED]>
To: "Nathan Wiger" <[EMAIL PROTECTED]>
Sent: Tuesday, April 24, 2001 4:08 PM
Subject: Re: YA string concat proposal
> On Tue, Apr 24, 2001 at 01:05:24PM -0700, Nathan Wiger wrote:
> > Under the above plan, maybe this is:
> >$a ca $b;
> > For "con
On Tue, 24 Apr 2001, Michael G Schwern wrote:
> On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote:
> > I think someone may have mentioned this already, but why not just say
> > that if you want '.' to mean concatenation, you have to surround it on
> > either side with white space?
On Tue, Apr 24, 2001 at 01:42:43PM -0700, Nathan Wiger wrote:
> Uri Guttman wrote:
> >
> > on the other hand, i use .= all the time and wouldn't like to lose
> > it. schwern idea of ce doesn't work for me as only the op= stuff means
> > assignment and ce would break that (e for = isn't visual eno
Michael G Schwern wrote:
>
> cc and ce
>
> Perl 5 Perl 6
> print "foo" . "bar";print "foo" cc "bar;
> print 2 . 4;print 2 cc 4;
> print "foo " . ($i + 1);print "foo " cc ($i + 1);
> $foo .= "
> 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,
Lightning flashed, thunder crashed and Garrett Goebel <[EMAIL PROTECTED]> w
hispered:
| cmp ~<=>
| .= ~+=
| ~=+ (concat after)
| =~ =~
| !~ !~
It's not bad enough that we're getting a proliferation of trigraph
operators, now you w
Actually, there are already languages named 'Parrot' and 'Poly' (links
below). Besides, I'm getting tired of animals . What about something
more fun, like "Magoo" or "Gilligan"? Or maybe we could move to insects, like
"Mantis" or "Wasp".
If we have to go with an animal, though, I like "Buzza
At 03:46 PM 4/24/2001 -0400, NeonEdge wrote:
>Actually, there are already languages named 'Parrot' and 'Poly' (links
>below). Besides, I'm getting tired of animals . What about something
>more fun, like "Magoo" or "Gilligan"? Or maybe we could move to insects, like
>"Mantis" or "Wasp".
The bi
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Other than that, I really don't care much, though a good (or bad)
DS> pun is always a big plus.
how about 'perm' which is 'perl'++
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCH
"Stephen P. Potter" wrote:
>
> Oh, and since it hasn't been mentioned for awhile, I'd still prefer if =~
> and !~ went away and were replaced by match(string, [pattern], options),
> replace(string, [pattern], options) and trans(string, ["pattern"], options)
> or some such. This is one place wher
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 aske
Dan Sugalski wrote:
> Most of the parser switching is going to be of the nesting variety. Every
> time the parser processes a double-quoted string constant or a regular
> expression you're going to be jumping parsers. That's all temporary, and we
> really do want them to nest. (You really don't w
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.
Rathe
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 _ $s
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";#
> | 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
> I still think it's a good idea - better than any other proposed so far.
>
> Are we so afraid of a little mandatory disambiguating white space
> that we are willing to pay the price of contorting other syntax
> beyond the bounds of sanity? :-)
>
> It's perfectly obvious to me that
>
> $x
"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 possibi
Uri Guttman wrote:
> i was looking at dan's PMC arena allocator struct and it reminded me of
> something an older language can do (which MJD has likened to an early
> perl :). ever heard of AREA in PL/I? it was a large chunk of ram
> dedicated to allocate memory from. what was special is that all
On Tue, 24 Apr 2001, Dan Sugalski wrote:
> The big reason for Parrot was that I was terribly amused by Simon's joke,
> and I have visions of releasing perl 6.0 on April 1 next year... :)
>
> Other than that, I really don't care much, though a good (or bad) pun is
> always a big plus.
Starting
On Tue, Apr 24, 2001 at 08:11:01PM -0400, Andy Dougherty wrote:
> On Tue, 24 Apr 2001, Dan Sugalski wrote:
>
> > The big reason for Parrot was that I was terribly amused by Simon's joke,
> > and I have visions of releasing perl 6.0 on April 1 next year... :)
> >
> > Other than that, I really do
On Tue, 24 Apr 2001 19:17:08 -0500, Jarkko Hietaniemi wrote:
>Wasn't Perl also taken, so why care...? I vaguely remember reading
>about another language called PERL...
It was "Pearl", AFAIK. That's why the "a" got missing. So I've been
told... ("Practical Extracting And Reporting Language"... y
Edward Peschko writes:
: I guess my question is what would be the syntax to access hashes? Would
:
: $hashref.{ }
:
: be that desirable? I really like ->{ } in that case..
It won't be either of those. It'll simply be $hashref{ }.
Larry
IMHO, . can DWIM in most cases even if it's both object deref _and_
concat--without paying any attention to whitespace.
Let's think about this for a minute. What are the common cases for use of
concat?
$a."b";
"a".$b;
$a.$b;
a.$b;
$a.b;
a.b;
The first two are obviously concat, since that code
On Tue, Apr 24, 2001 at 06:54:18PM -0700, Larry Wall wrote:
> Nick Ing-Simmons writes:
> : Larry Wall <[EMAIL PROTECTED]> writes:
> : >I think using overloading to write a parser is going to be a relic of
> : >Perl 5's limitations, not Perl 6's.
> :
> : I am _NOT_ using overloading to write a par
On Tue, Apr 24, 2001 at 06:39:09PM -0700, Larry Wall wrote:
> Edward Peschko writes:
> : I guess my question is what would be the syntax to access hashes? Would
> :
> : $hashref.{ }
> :
> : be that desirable? I really like ->{ } in that case..
>
> It won't be either of those. It'll simply be
Dan Sugalski writes:
: Resizing the vtable at runtime is a really dodgy thing. There are some
: rather huge threading implications here--changing their size (as opposed to
: using up a limited number of "uncommitted" spots we leave at the end) means
: potentially having to move all the vtables
Nick Ing-Simmons writes:
: Larry Wall <[EMAIL PROTECTED]> writes:
: >I think using overloading to write a parser is going to be a relic of
: >Perl 5's limitations, not Perl 6's.
:
: I am _NOT_ using overloading to write a parser.
: Parse::Yapp is just fine for writing parsers. I am trying to re-
Dan Sugalski writes:
: Unless Larry says otherwise, this:
:
:my num @foo;
:
: will have the data portion of the @foo PMC point off to a block of memory
: with floats jammed end-to-end in it.
I'm not going to say other.
Larry
1 - 100 of 107 matches
Mail list logo
