On Monday 09 May 2005 19:36, Autrijus Tang wrote:
On Mon, May 09, 2005 at 10:51:53PM +1000, Damian Conway wrote:
Autrijus wrote:
/me eagerly awaits new revelation from Damian...
Be careful what you wish for. Here's draft zero. ;-)
...and here is my status report of the Zero-Day exploit,
Larry Wall wrote:
On Mon, May 09, 2005 at 12:14:35PM -0700, Larry Wall wrote:
: On Mon, May 09, 2005 at 02:08:31PM -0500, Patrick R. Michaud wrote:
: : Hmmm, then would $x.$j.2 then be equivalent to $x[$j-1][1] ?
:
: Ouch.
Maybe that's a good reason to switch from 1-based to 0-based
$digit
Patrick R. Michaud wrote:
On Mon, May 09, 2005 at 09:14:02AM -0700, Larry Wall wrote:
: m/ alt: tea (don't) (ray) (me) (for) (solar tea), (d'oh!)
: | alt: BEM (every) (green) (BEM) (devours) (faces)
: /;
This seems like a rather ugly syntax for what is essentially a label,
or a
DC rule mv { $lastcmd:=(mv) $files:=[ ident ]+
$dir:=ident }
DC rule cp { $lastcmd:=(cp) $files:=[ ident ]+
$dir:=ident }
DC sub lastcmd { return $lastcmd }
DC }
DC while shift ~~ m/Shell::Commands.cmd/ {
DC say From: @{$files};
DC
Damian Conway writes:
Just as $42 is a shorthand for $/[42], so too $whatever is a
shorthand for $/whatever.
Isn't $42 a shorthand for $/[41] ?
I think that having 1-based digit-variables but 0-based array indexes on
$/ is really confusing; mistakes of this sort seem to confirm my view.
--
On 5/10/05, Aaron Crane [EMAIL PROTECTED] wrote:
Damian Conway writes:
Just as $42 is a shorthand for $/[42], so too $whatever is a
shorthand for $/whatever.
Isn't $42 a shorthand for $/[41] ?
I think that having 1-based digit-variables but 0-based array indexes on
$/ is really
Hi,
sub foo() {
abc ~~ /^(.)/; # $1 now a
}
sub bar() {
def ~~ /^(.)/; # $1 now d
foo();
say $1;# Outputs d
}
bar();
# Correct (I hope so)?
--Ingo
--
Linux, the choice of a GNU | Row, row, row your bits, gently down the
On 5/10/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
Hi,
sub foo() {
abc ~~ /^(.)/; # $1 now a
}
sub bar() {
def ~~ /^(.)/; # $1 now d
foo();
say $1;# Outputs d
}
bar();
# Correct (I hope so)?
Yeah, they're lexical, just like in
Second attempt and cc'ed to other Perl lists too.
Original Message
Subject: [PROPOSAL] call syntax abstraction
Date: Tue, 03 May 2005 13:58:14 +0200
Comments welcome,
leo
=head1 TITLE
Calling convention abstraction
=head1 ABSTRACT
The current Parrot calling conventions as
DC == Damian Conway [EMAIL PROTECTED] writes:
DC rule mv { $lastcmd:=(mv) $files:=[ ident ]+ $dir:=ident }
DC rule cp { $lastcmd:=(cp) $files:=[ ident ]+ $dir:=ident }
DC sub lastcmd { return $lastcmd }
DC }
DC while shift ~~ m/Shell::Commands.cmd/ {
DC say From: @{$files};
DC
In Pugs, the current logic for array submatches in split() is
to stringify each element, and return them separately in the
resulting list. To wit:
pugs split /(..)*/, 1234567890
('', '12', '34', '56', '78', '90')
Is this sane?
Thanks,
/Autrijus/
pgpoNrOaK2bLb.pgp
Description: PGP
Luke Palmer [EMAIL PROTECTED] writes:
On 5/5/05, Terrence Brannon [EMAIL PROTECTED] wrote:
I was looking at a line in the hangman program:
@letters == @solution.grep:{ $_ ne '' };
and was told that I was looking at an adverbial block.
The adverbial block is what you're giving to `if`
Ashley, this is a great post. I have included it almost verbatim in my
p6 talk I'm giving tomorrow at our Perl Monger's meeting:
http://www.metaperl.com/talks/p6/hangman-elucidated/slide6.html
I hope you don't mind.
On 5/5/05, Terrence Brannon [EMAIL PROTECTED] wrote:
I was looking at a
Juerd wrote:
No, again, please do not make the mistake of thinking VALUES have
identity. VARIABLES (containers) do. A reference points to a container,
never to a value directly.
I don't consider it a mistake. So, you dany identity to fat values
like database connections or GUI objects?
This is
Thomas Sandlaß skribis 2005-05-10 19:02 (+0200):
Juerd wrote:
No, again, please do not make the mistake of thinking VALUES have
identity. VARIABLES (containers) do. A reference points to a container,
never to a value directly.
I don't consider it a mistake.
That is a problem.
So, you
I am wondering what the proper behavior of binding to a sub's return
value should be
sub some_routine {
my $foo = 42;
return $foo;
}
my $rv := some_routine();
Should $rv be bound to $foo or to a copy of $foo? I ask because with
state() and closures, it makes a difference since the value
Joshua Gatcomb skribis 2005-05-10 15:52 (-0400):
sub some_routine {
my $foo = 42;
return $foo;
}
my $rv := some_routine();
Should $rv be bound to $foo or to a copy of $foo? I ask because with
state() and closures, it makes a difference since the value can
change.
:= is the thing
On Tue, May 10, 2005 at 06:20:44AM -0600, Luke Palmer wrote:
On 5/10/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
Hi,
sub foo() {
say $1;# undef?
abc ~~ /^(.)/; # $1 now a
}
sub bar() {
def ~~ /^(.)/; # $1 now d
foo();
say
On Tue, May 10, 2005 at 05:24:30PM -0400, Rick Delaney wrote:
: On Tue, May 10, 2005 at 06:20:44AM -0600, Luke Palmer wrote:
: Yeah, they're lexical, just like in Perl 5.
:
: Not just like Perl 5, I hope. If it was then the above would print
: d.
Yes, Perl 5 actually uses an autolocalizing
Juerd [EMAIL PROTECTED] wrote:
:= is the thing that implements subroutine arguments. Ask yourself the
same question with:
sub another_routine ($rv) {
...
}
another_routine(some_routine());
I'd expect $rv to be an alias to a copy of $foo's value, 42.
Really? Because
20 matches
Mail list logo
