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, if you changed Perl's syntax too radically
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 c
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 poin
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 $ugl
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"
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 liv
At 04:40 PM 23/04/2001 -0400, John Porter wrote:
>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.
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
fas
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
> changin
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 c
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!
:
:
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 t
Graham Barr wrote:
> The other choice is not to have a concat operator but instead have
> C, 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
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, 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 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
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, 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: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
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
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?
> 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
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
At 09:06 PM 4/24/2001 -0700, Larry Wall wrote:
>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.
I was teaching an intro class yesterday and as usual, there were
John Porter wrote:
> We could y/$@%/@%$/ ...
... and create an alternate parser able to handle the full
internal internals API.
I have finally figured out the main motivation behind the
whole perl6 effort: the obfuscated perl contests were
getting repetitive.
Good night.
On Tue, 24 Apr 2001 18:39:09 -0700 (PDT), 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 $hashre
On Tue, 24 Apr 2001 21:06:56 -0700 (PDT), Larry Wall wrote:
>: 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.
Ok. So how about hash slices? Is $hash{$a, $b}, the faked
multidimension
Bart Lateur writes:
: Ok. So how about hash slices? Is $hash{$a, $b}, the faked
: multidimensional hash, going to go?
Yes, fake multidimensional hashes will be defenestrated.
Larry
Bart Lateur writes:
: Er... hip hip hurray?!?!
:
: This is precisely the reason why I came up with the raw idea of
: highlander variables in the first place: because it's annoying not being
: able to access a hash passed to a sub through a hash reference, in the
: normal way. Not unless you do al
From: [EMAIL PROTECTED] (Randal L. Schwartz)
Date: 25 Apr 2001 07:23:44 -0700
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Lines: 50
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
> "Peter" == Peter Scott <[EMA
Nathan Wiger wrote:
>
>Here's something I was thinking about at lunch:
>
> $concated_number = "$number" + "$other_number";
> $numerical_add = $number + $other_number;
>
One major, MAJOR pet peeve I have wrt Javascript is that it uses
+ to mean concatenation as well as addition, and that it
On Mon, Apr 23, 2001 at 12:59:54PM -0700, Nathan Wiger wrote:
> > Doesn't ~ look like a piece of string to you? :-)
> It looks like a bitwise op to me, personally.
That's because every time you've used it in Perl, it's been a bitwise
op. Sapir-Whorf, and all that.
--
So what if I have a fertil
On Wed, Apr 25, 2001 at 06:46:20PM +0100, Simon Cozens wrote:
> On Mon, Apr 23, 2001 at 12:59:54PM -0700, Nathan Wiger wrote:
> > > Doesn't ~ look like a piece of string to you? :-)
> > It looks like a bitwise op to me, personally.
>
> That's because every time you've used it in Perl, it's been
On Wed, 25 Apr 2001 06:09:56 -0700 (PDT), Larry Wall wrote:
>Bart Lateur writes:
>: Er... hip hip hurray?!?!
>:
>: This is precisely the reason why I came up with the raw idea of
>: highlander variables in the first place: because it's annoying not being
>: able to access a hash passed to a sub
Bart Lateur wrote:
> Yeah. But no cheers then. The problem still remains: you can access a
> hash in the normal way in plain code, but inside a sub, you can mainly
> only access a passed hash through a reference.
>
> ...
>
> Are you going to provide a simpler aliasing mechanism to turn a hash
>
Bart Lateur <[EMAIL PROTECTED]> writes:
>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="${P
Bart Lateur writes:
: Yeah. But no cheers then. The problem still remains: you can access a
: hash in the normal way in plain code, but inside a sub, you can mainly
: only access a passed hash through a reference.
Won't be a problem.
: It's annoying to basically having two ways of doing somethin
43 matches
Mail list logo
