On Wed, May 09, 2001 at 02:05:48PM -0700, Austin Hastings wrote:
> Will it be possible to define "pointer classes", a la C++, in a
> relatively "smooth" manner?
>
> That is, an object R has methods of its own as well as methods
> belonging to the "referred to" object?
Sounds you're looking for a
Will it be possible to define "pointer classes", a la C++, in a
relatively "smooth" manner?
That is, an object R has methods of its own as well as methods
belonging to the "referred to" object?
E_G: print "$R.toString is a reference to $R->toString";
Or some such? The notion of $R.getData.toStr
James Mastros <[EMAIL PROTECTED]> writes:
>From: "Larry Wall" <[EMAIL PROTECTED]>
>Sent: Monday, April 23, 2001 1:10 PM
>Subject: Re: Tying & Overloading
>> Helgason writes:
>> : I _really_ think dot-syntax would make perl prettier as well
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
At 05:41 PM 4/30/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: At 03:08 PM 4/25/2001 -0300, Branden wrote:
>:
>: >At 01:52 PM 25/04/2001 -0400, Dan Sugalski wrote:
>: >>Seriously, I don't see why this should be a scary thing. So, the opcode
>: >>table's extendable. So what? It'll make lan
At 11:05 PM 4/30/2001 +0200, Kai Henningsen wrote:
>[EMAIL PROTECTED] (Dan Sugalski) wrote on 25.04.01 in
><[EMAIL PROTECTED]>:
>
> > If you have the double-indirect, the window of vulnerability is smaller,
> > but it's still there if you're running multithreaded.
>
>Looks zero-sized to me. One
[EMAIL PROTECTED] (Dan Sugalski) wrote on 25.04.01 in
<[EMAIL PROTECTED]>:
> If you have the double-indirect, the window of vulnerability is smaller,
> but it's still there if you're running multithreaded.
Looks zero-sized to me. One memory write, let the garbage collector
collect the old vt
Dan Sugalski writes:
: At 03:08 PM 4/25/2001 -0300, Branden wrote:
:
: >At 01:52 PM 25/04/2001 -0400, Dan Sugalski wrote:
: >>Seriously, I don't see why this should be a scary thing. So, the opcode
: >>table's extendable. So what? It'll make language X mode simpler, for some
: >>value of X, if
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 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
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
On Wed, 25 Apr 2001, James Mastros wrote:
> I hate yelling without good reason, but this /is/ good reason. CAN SOMBODY
> PLEASE TELL ME A _GOOD_ REASON TO SWITCH TO . FOR METHOD CALLS?
It might be prudent to avoid rushing to judgment until the bigger picture
becomes clearer. We have yet to see
At 03:08 PM 4/25/2001 -0300, Branden wrote:
>At 01:52 PM 25/04/2001 -0400, Dan Sugalski wrote:
>>Seriously, I don't see why this should be a scary thing. So, the opcode
>>table's extendable. So what? It'll make language X mode simpler, for some
>>value of X, if that language can load in its own
At 11:01 AM 4/25/2001 -0300, Branden wrote:
>At 09:39 AM 25/04/2001 -0400, Dan Sugalski wrote:
>>At 06:46 PM 4/24/2001 -0700, Larry Wall wrote:
>>>I think we definitely have to be able to resize vtables at compile time,
>>>which is a form of run time. It's vaguely possible we could restrict
>>>mu
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
At 02:01 PM 4/25/2001 -0300, Branden wrote:
>At 11:34 AM 25/04/2001 -0400, Dan Sugalski wrote:
>>At 11:01 AM 4/25/2001 -0300, Branden wrote:
>>>2) Anyway, even resizing vtables we would need some more indirection to
>>>determine in which position of the vtable is which operator.
>>
>>No. Each ope
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
At 01:52 PM 25/04/2001 -0400, Dan Sugalski wrote:
>Seriously, I don't see why this should be a scary thing. So, the opcode
>table's extendable. So what? It'll make language X mode simpler, for some
>value of X, if that language can load in its own set of extended opcodes.
>Perhaps someone'll w
On Wed, Apr 25, 2001 at 12:44:11PM -0400, James Mastros wrote:
> I hate yelling without good reason, but this /is/ good reason. CAN SOMBODY
> PLEASE TELL ME A _GOOD_ REASON TO SWITCH TO . FOR METHOD CALLS?
You've made it impossible for anyone to answer you until you tell us
what "good" means to
At 11:34 AM 25/04/2001 -0400, Dan Sugalski wrote:
>At 11:01 AM 4/25/2001 -0300, Branden wrote:
>>2) Anyway, even resizing vtables we would need some more indirection to
>>determine in which position of the vtable is which operator.
>
>No. Each operator goes in a fixed position in the vtable, and
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
From: "Larry Wall" <[EMAIL PROTECTED]>
Sent: Monday, April 23, 2001 1:10 PM
Subject: Re: Tying & Overloading
> Helgason writes:
> : I _really_ think dot-syntax would make perl prettier as well as make it
> : more acceptable to the world of javacsharpbasic droids. W
At 04:12 PM 25/04/2001 +0200, Bart Lateur wrote:
>On Wed, 25 Apr 2001 11:01:07 -0300, Branden wrote:
> >If the idea is supporting arbitrary add-on operators...
>
>I think I second that. I would think of a fixed table for the built-in
>ones, and a linked list for the add-ons. It's not necessary tha
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
At 09:39 AM 25/04/2001 -0400, Dan Sugalski wrote:
>At 06:46 PM 4/24/2001 -0700, Larry Wall wrote:
>>I think we definitely have to be able to resize vtables at compile time,
>>which is a form of run time. It's vaguely possible we could restrict
>>multithreading during compile phase.
>
>We need to
On Wed, 25 Apr 2001 11:01:07 -0300, Branden wrote:
>If the idea is supporting arbitrary add-on operators, which I believe will
>be done seldom, for only some specific classes, wouldn't it be better to
>have a ``catch all'' entry for operators different than the built-in ones?
>
>Of course, add-
At 06:46 PM 4/24/2001 -0700, Larry Wall wrote:
>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) mea
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
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
On Tue, Apr 24, 2001 at 01:18:49PM +0100, Nick Ing-Simmons wrote:
> What _really_ want to do is a dynamically scoped peep-hole "optimize"
> (actually a rewrite) of the op tree - written in perl.
>
> But I can't do that
Yes, you can. Check out B::Generate.
--
Britain has football hooligans, Ger
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
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
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.
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
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.
$these=$this$that$the_
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 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
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
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:
: 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
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
> 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
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?
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, 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
> 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 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
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 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, 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 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
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 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 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
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
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
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
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
> 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
'æ',
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
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
> 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
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
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.
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 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
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
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
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 p
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
>I am not sure I do like the use of ~ here. It does not screan concatenate
to me (but then again neither did . when I started perl)
>I am thinking that maybe it should be a 2 character operator with at least
one of then being + as + is common in many other languages for doing
concatenation.
How
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!
:
:
At 04:46 PM 4/23/2001 -0400, John Porter wrote:
>Larry Wall wrote:
> > Except we're not having highlander variables. $foo and @foo remain
> > distinct entities.
>
>I know. Sad.
>
>(Of course, what I meant by highlander was no prefix chars.
>Highlanderishness is just a consequence of that.)
It w
On Mon, Apr 23, 2001 at 01:23:43PM -0600, Nathan Torkington wrote:
> Larry Wall writes:
> > wanted, you still get the length. If you're worried about the delayed
> > operation, you can force numeric context with $x = +@tmp;, just as you
> > can force string context with a unary ~.
>
> How often
Larry Wall writes:
> wanted, you still get the length. If you're worried about the delayed
> operation, you can force numeric context with $x = +@tmp;, just as you
> can force string context with a unary ~.
How often are you likely to do this? Speaking as a reader of code,
I've always hated una
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
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
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
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.
Larry Wall wrote:
> Except we're not having highlander variables. $foo and @foo remain
> distinct entities.
I know. Sad.
(Of course, what I meant by highlander was no prefix chars.
Highlanderishness is just a consequence of that.)
--
John Porter
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 07:11 PM 4/20/2001 -0500, Jarkko Hietaniemi wrote:
>On Fri, Apr 20, 2001 at 05:02:21PM -0700, Larry Wall wrote:
> > Jarkko Hietaniemi writes:
> > : What is someone wants to define matrices and have both cross product
> > : and dot product?
> >
> > At some point, there aren't enough operators, a
[This started out just as a response, but I've been wading through the
original post at the same time so it sort of drifts]
At 02:47 PM 4/23/2001 -0300, Filipe Brandenburger wrote:
>At 05:21 PM 20/04/2001 -0400, Dan Sugalski wrote:
>>At 06:08 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
>>>I'd
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"
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
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
[EMAIL PROTECTED] writes:
: On 4/23/01 3:25 PM, Larry Wall wrote:
: > : >From a trainer's point of view, having two operators which look very
: > similar, : are used for the same thing in various different languages, and do
: > *almost* : the same thing but not quite, is completely *asking* for co
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
John Porter writes:
: Larry Wall wrote:
: > I do expect that @() and $() will be used for interpolating list and
: > scalar expressions into strings, and it is probably the case the $()
: > would be a synonym for scalar(). @() would then be a synonym for
: > the mythical list() operator. Which p
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
Graham Barr writes:
: On Mon, Apr 23, 2001 at 11:40:50AM -0700, Larry Wall wrote:
: > I do expect that @() and $() will be used for interpolating list and
: > scalar expressions into strings, and it is probably the case the $()
: > would be a synonym for scalar(). @() would then be a synonym for
On 4/23/01 3:25 PM, Larry Wall wrote:
> : >From a trainer's point of view, having two operators which look very
> similar, : are used for the same thing in various different languages, and do
> *almost* : the same thing but not quite, is completely *asking* for confusion.
>
> So teach 'em :=, and
At 07:44 PM 04-23-2001 +0100, Graham Barr wrote:
>Hm, I would expect @() in a scalar context to give the
>same result as
>
> @tmp = @(...); $x = @tmp;
>
>That is, yeild the number of elements in the list.
I can see this. But unless there is a good reason, that seems like a
less-than-optimal
On Mon, 23 Apr 2001 13:19:24 +0100, Graham Barr wrote:
>> Or we change the concatenation operator.
>I am thinking that maybe it should be a 2 character operator with at
>least one of then being + as + is common in many other languages
>for doing concatenation.
Or, in analogy to "cmp", "gt" etc:
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 perl5 and write perl 6. This works for all ex
Larry Wall wrote:
> I do expect that @() and $() will be used for interpolating list and
> scalar expressions into strings, and it is probably the case the $()
> would be a synonym for scalar(). @() would then be a synonym for
> the mythical list() operator. Which probably, in Perl 6, turns out
Simon Cozens writes:
: On Mon, Apr 23, 2001 at 11:48:35AM -0700, Larry Wall wrote:
: > :@foo = @( a + b ); # element by element add of @a and @b
: > I expect that's be written:
: >
: > @foo := @a + @b;
:
: Two different assignment operators? I can understand the intent, but this kind
:
Bart Lateur writes:
: Or, in analogy to "cmp", "gt" etc:
:
: $a = $b plus $c;
: or
: $a = $b cat $c;
It would probably have been C if it had come to that.
Larry
On Mon, Apr 23, 2001 at 09:05:22PM +0200, Bart Lateur wrote:
> Or, in analogy to "cmp", "gt" etc:
> $a = $b plus $c;
> or
> $a = $b cat $c;
while left_angle_right_angle:
if dollar_underscore[0] =eq= "#":
continue_next;
}
print dollar_underscore;
On Mon, Apr 23, 2001 at 11:48:35AM -0700, Larry Wall wrote:
> :@foo = @( a + b ); # element by element add of @a and @b
> I expect that's be written:
>
> @foo := @a + @b;
Two different assignment operators? I can understand the intent, but this kind
of difficult-to-remember special-cas
1 - 100 of 154 matches
Mail list logo
