Nathan Wiger [EMAIL PROTECTED] writes:
- C compatibility. One of Perl's great strengths
over other HLL's is C compatibility. Though
this is still arguably not as good as it can be,
why distance ourselves from the language we're
trying to interact with?
You're
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
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
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, 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]
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
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: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:
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...
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
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
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
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
On 4/23/01 3:59 PM, Nathan Wiger wrote:
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
At 12:59 PM 23/04/2001 -0700, Nathan Wiger wrote:
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,
At 04:14 PM 23/04/2001 -0400, John Siracusa wrote:
On 4/23/01 3:59 PM, Nathan Wiger wrote:
Then how do you concatenate a number?
Using + for concat: no!
My vote is to use . and require space before and after.
$this.$is.$ugly.$anyway ;)
People who use one-liners know the value of
On Mon, 23 Apr 2001 16:14:50 -0400, John Siracusa wrote:
Using + for concat: no!
My vote is to use . and require space before and after.
$this.$is.$ugly.$anyway ;)
My vote is to ditch the concat operator altogether. Hey, we have
interpolation!
$this$is$just$as$ugly$but$it$works
Which
Nathan Wiger wrote:
if you changed Perl's syntax too radically you
would almost certainly lose programmers.
I disagree. Changing the semantics of Perl to make it more
powerful is something every perl programmer would be happy
about. Consequent changes to the syntax is something we
would live
John Porter wrote:
One of the reasons I program in Perl as my
primary language is *because of* the syntax.
With all due respect, I don't believe that's why you,
or anyone else, likes to program in Perl.
I *really* don't want this to turn into a religious argument, which it's
fast
Branden wrote:
Changing the semantics of Perl to make it more
powerful is something every perl programmer would be happy
about. Consequent changes to the syntax is something we
would live with.
I don't see the semantic change to make it more powerful that is behind
changing - to .
Nathan Wiger wrote:
I *really* don't want this to turn into a religious argument,
Neither do I.
coming from a sh/C background.
I understand. I think I was able to learn Perl as quickly
as I did because of certain syntactic similarities.
But it's not why I program in Perl now, and it's
Bart Lateur writes:
: On Mon, 23 Apr 2001 16:14:50 -0400, John Siracusa wrote:
:
: Using + for concat: no!
:
: My vote is to use . and require space before and after.
: $this.$is.$ugly.$anyway ;)
:
: My vote is to ditch the concat operator altogether. Hey, we have
: interpolation!
:
:
In 12839.969393548@chthon, Tom Christiansen writes:
:What can be done to make $ work "better", so we don't have to
:make people use /foo\z/ to mean /foo$/? They'll keep writing
:the $ for things that probably oughtn't abide optional newlines.
:
:Remember that /$/ really means /(?=\n?\z)/. And
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
Could you explain what the problem is?
TC /$/ does not only match at the end of the string.
TC It also matches one character fewer. This makes
TC code like $path =~ /etc$/ "wrong".
Sorry, I'm missing it.
$_ = "etc\n"; /etc$/;
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
Could you explain what the problem is?
TC /$/ does not only match at the end of the string.
TC It also matches one character fewer. This makes
TC code like $path =~ /etc$/ "wrong".
Sorry, I'm missing it.
I know.
On your "longest match",
On Wed, 20 Sep 2000 10:03:08 +0100, Hugo wrote:
In 12839.969393548@chthon, Tom Christiansen writes:
:What can be done to make $ work "better", so we don't have to
:make people use /foo\z/ to mean /foo$/? They'll keep writing
:the $ for things that probably oughtn't abide optional newlines.
Gee
That was my second thought. I kinda like it, because //s would have two
effects:
+ let . match a newline too (current)
+ let /$/ NOT accept a trailing newline (new)
Don't forget /s's other meaning.
--tom
Tom Christiansen wrote:
Don't forget /s's other meaning.
Do you enjoy making people ask what you're talking about? What other
meaning did you have in mind, overriding $*?
--
Robert Mathews
Software Engineer
Excite@Home
301 - 332 of 332 matches
Mail list logo
