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
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
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 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 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
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
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
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, 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
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
> 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
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
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:
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
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
Glenn Linderman writes:
: Why not
:
:@foo = @( a + b ); # element by element add of @a and @b
I expect that's be written:
@foo := @a + @b;
where the := says to treat the left side as a prototype, and a bare
array in a prototype is going to put scalar context on the right side,
and a
At 10:10 AM 4/23/2001 -0700, Larry Wall wrote:
>=?iso-8859-1?Q?Dav=ED=F0?= Helgason writes:
>: I _really_ think dot-syntax would make perl prettier as well as make it
>: more acceptable to the world of javacsharpbasic droids. Which is some
>: kind of goal, no?
>
>Consider it a given that we'll be
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
> the mythical list() operat
[EMAIL PROTECTED] writes:
: Okay, then:
:
: @foo = @( @a + @b );# @(), $(), and %() set context.
:
: Easier to identify the operators, and little or no question about the
: context...
Well, sure, though it was already in list context from the assignment...
I do expect that @() and
Why not
@foo = @( a + b ); # element by element add of @a and @b
or even
@( foo = a + b ); # element by element add of @a and @b assigned to
@foo.
I guess one could claim the idea is similar to the old BASIC MAT prefix,
although it was clearly reached by a different path. This could
Nathan Wiger writes:
: Larry Wall wrote:
: >
: > : I _really_ think dot-syntax would make perl prettier as well as make it
: > : more acceptable to the world of javacsharpbasic droids. Which is some
: > : kind of goal, no?
: >
: > Consider it a given that we'll be using . for dereferencing. (Po
Okay, then:
@foo = @( @a + @b );# @(), $(), and %() set context.
Easier to identify the operators, and little or no question about the
context...
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> Stephen P. Potter writes:
> : Maybe this is a crazy (or stupid) idea, but why couldn't we us
Okay, then:
@foo = @( @a + @b );# @(), $(), and %() set context.
Easier to identify the operators, and little or no question about the
context...
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> Stephen P. Potter writes:
> : Maybe this is a crazy (or stupid) idea, but why couldn't we us
Lightning flashed, thunder crashed and Larry Wall <[EMAIL PROTECTED]> whispered:
| I'm thinking concat will be ~. Furthermore, I'm thinking unary ~ will
| be stringify, and unary ^ will be bit complement, on the theory that
| bit complement is like xoring with 0x. And unary + will be a
|
Stephen P. Potter writes:
: Maybe this is a crazy (or stupid) idea, but why couldn't we use the $, @,
: and % characters?
:
: @foo = @a @+ @b; # element by element add
Because it's difficult to tell the operators from the terms visually.
Larry
Larry Wall wrote:
>
> : I _really_ think dot-syntax would make perl prettier as well as make it
> : more acceptable to the world of javacsharpbasic droids. Which is some
> : kind of goal, no?
>
> Consider it a given that we'll be using . for dereferencing. (Possibly
> with -> as a synonym, just
Lightning flashed, thunder crashed and Graham Barr <[EMAIL PROTECTED]> whispered:
| > What's wrong with something like:
| >
| >$foo = $a :+ $b;
|
| I was thinking along those lines too.
Maybe this is a crazy (or stupid) idea, but why couldn't we use the $, @,
and % characters?
@foo =
=?iso-8859-1?Q?Dav=ED=F0?= Helgason writes:
: I _really_ think dot-syntax would make perl prettier as well as make it
: more acceptable to the world of javacsharpbasic droids. Which is some
: kind of goal, no?
Consider it a given that we'll be using . for dereferencing. (Possibly
with -> as a s
On Mon, Apr 23, 2001 at 12:36:47PM -0400, Dan Sugalski wrote:
> At 02:52 PM 4/23/2001 +0200, Davíð Helgason wrote:
> >"H.Merijn Brand" wrote:
> > >
> > > > > $a = $b ~ $c; # Mmm!
> > > > >
> > > > > I like that last one a lot, because it doesn't disturb anything.
> > > > > You'd have to alter ~'s
On Mon, Apr 23, 2001 at 12:36:47PM -0400, Dan Sugalski wrote:
> What's wrong with something like:
>$foo = $a :+ $b;
Well, at least it's colon rule compliant.
--
You want to read that stuff, fine. You want to create a network for such
things, fine. You want to explore the theoretical bounda
At 02:52 PM 4/23/2001 +0200, Davíð Helgason wrote:
>"H.Merijn Brand" wrote:
> >
> > > > $a = $b ~ $c; # Mmm!
> > > >
> > > > I like that last one a lot, because it doesn't disturb anything.
> > > > You'd have to alter ~'s precedence so that binary ~ is higher
> > > > than named unary operators. (I
At 11:02 AM 4/23/2001 -0400, John Porter wrote:
>Simon Cozens wrote:
> > John Porter wrote:
> > > $a = $b $c;
> >
> > Actually, I'd rather like that to be equivalent to
> > $a = $c->$b;
>
>Oops, sorry, I forgot the smiley.
>
>Oh, but thinking seriously about it:
>do we really want to keep th
Simon Cozens wrote:
> John Porter wrote:
> > $a = $b $c;
>
> Actually, I'd rather like that to be equivalent to
> $a = $c->$b;
Oops, sorry, I forgot the smiley.
Oh, but thinking seriously about it:
do we really want to keep the "indirect object" syntax?
It is said to be a major source of
On Mon, Apr 23, 2001 at 10:48:53AM -0400, John Porter wrote:
> Perl: Snobol with embedded gravel.
> $a = $b $c;
*snort*
Actually, I'd rather like that to be equivalent to
$a = $c->$b;
--
Complete the following sentence: People *ought* to weigh bricks, cats
and cinnamon in the same units
Simon Cozens wrote:
> Or we change the concatenation operator.
Perl: Snobol with embedded gravel.
$a = $b $c;
--
John Porter
1 - 100 of 109 matches
Mail list logo
