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 in perl now too, so
perl is already quite standard in
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 requirement to predeclare all variables would come into
Larry Wall wrote:
Okay, but it's just as many characters to say - as it is \., y'know.
Yep. But I'll plead rule #1 for myself, and let it go.
(The other thought I had was that slashes might be nice, since
some filesystem hierarchies use it. But then the division op
gets squeeged.
Hm. Maybe
Graham Barr wrote:
The other choice is not to have a concat operator but instead have
Cconcat LIST, but I guess not many people would like that either.
sub concat(@) { join '', @_ }
Seems to me like the sort of thing that ought to be in the core.
--
John Porter
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 shell
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.method
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 favor.
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.
A
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 depend on
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 -MO=Terse
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
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 downside
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 (and Perl 5
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 remember that
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.
Because
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 course of
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 a struct
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 am
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 that
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) but there are many
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 what
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
#,
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 now in Perl, an
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 in perl
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 forced
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 confusion
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
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
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
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
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
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
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
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
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
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 with
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...
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; $a =
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
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
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
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
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...
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 .= bar ;
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:
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 in muck
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;
: print foo .
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 only needed
~ 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 ~==
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
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
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
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 concat after?
I'd
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 enough).
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
|
| 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
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 = $foo
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:
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 where I
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 want
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
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;
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 parser.
:
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
At 06:40 PM 4/24/2001 -0500, David L. Nicol wrote:
Dan Sugalski wrote:
[BTW, was this meant to be CC'd to one of the perl 6 lists? My copy wasn't]
yeah, I have perl6-language as a alias but not language by itself
Fixed.
At 05:55 PM 4/24/2001 -0500, David L. Nicol wrote:
Dan Sugalski
Edward Peschko writes:
: Ok, so what does:
:
: my %hash = ( 1 = 3);
: my $hash = { 1 = 4};
:
: print $hash{1};
:
: print?
4. You must say %hash{1} if you want the other.
Larry
Larry Wall wrote:
(And juxtaposition is out because we're not going to destroy indirect
object syntax
How often is indirect object syntax used without some whitespace? Having
the perl5-perl6 converter locate it and insert a space shouldn't be too
very tricky.
1: use adjacency w/o white space for string cat.
2: allow, as in C, consecutive double-quoted strings
with no intervening tokens (i.e. just whitespace and comments) to
be considered as one string
3: as Uri pointed out, it's all syntactic sugar for convolutions
of Cjoin
That
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
On Tue, Apr 24, 2001 at 02:01:11AM -0700, Damien Neil wrote:
If you're dead-set on reassigning ., please consider leaving it at
that, rather than juggling all the other operators around.
Don't forget that binary ~ doesn't currently exist, so this is adding
syntax rather than reassigning it.
81 matches
Mail list logo
