It's still largely incomplete, and getting a little weighty, so v.2 is up
on my web page:
http://members.home.net/bcwarno/Perl6/ref/statements.txt
I'm sure I didn't cover all the corrections from the first go round, so if I
missed anything, gently poke me in the side.
What's been added?
B
On Wed, Sep 05, 2001 at 09:02:00PM -0400, Bryan C. Warnock wrote:
> Hmm is this such a good thing?
Using goto LABEL? No. ;)
Would be nice if Perl warned one about multiple labels of the same
name in the same call stack, though.
> my $a = 0;
> GORK: while( 1 ) {
> print "Rin ";
Hmm is this such a good thing?
my $a = 0;
GORK: while( 1 ) {
print "Rin ";
GORK: if ( 1 ) {
print "Tin ";
goto GORK if $b ^= 1;
print "\n";
next GORK;
}
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
Dan Sugalski wrote:
[... massive sniping snippage ...]
> The problem I was talking about was those cases where we have a good but
> not perfect match at compile time. In the case you gave, we assume that @A
> are full of fish, so dispatch to the "multiple fish parameter" version of
> list_medica
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
> > > * Methods get their parameters passed in as a list in PMC register 0,
> > > * unless we can unambiguously figure out their prototype at
> > > * compilation time
> >
> >Will the subroutine know how it
At 11:17 AM 9/5/2001 -0700, Hong Zhang wrote:
>Howerver, I like to point out one hidden overhead of register opcode is
>decoding the parameter. The add instrction of stack machine does not have
>args, but for register machine, it has 3 arguments.
I skipped the decoding step in the machine design
> If you really want a comparison, here's one. Take this loop:
>
> i = 0;
> while (i < 1000) {
>i = i + 7;
> }
>
> with the ops executed in the loop marked with pipes. The corresponding
> parrot code would be:
>
> getaddr P0, i
> store P0, 0
>
> True, but it is easier to generate FAST code for a register machine.
> A stack machine forces a lot of book-keeping either run-time inc/dec of
sp,
> or alternatively compile-time what-is-offset-now stuff. The latter is a
real
> pain if you are trying to issue multiple instructions at once.
I
[I'm answering these out of order--sorry. Already answered elsewhere bits
snipped]
At 02:28 PM 9/5/2001 +0200, Paolo Molaro wrote:
>On 09/04/01 Dan Sugalski wrote:
> > > More on this point later in the mail.
> > >There's a reason for that: register virtual machines are more complex
> > >and more
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> stack machine -> post-order walk of the tree
>>
>> reg machine -> instruction selection -> register allocation ->
DS> So what? That happens exactly once, in the compilation phase. Yes, it means
DS> compilation will be somewhat
[EMAIL PROTECTED] wrote:
> Clearly caller() isn't what we want here, but I'm not
> quite sure what would be the correct incantation.
I've always assumed that a BEGIN block's caller() will
be the compiler. This makes it easy for the compiler to
lie about %MY:: and use the lexical scope being compi
At 03:19 PM 9/5/2001 +0200, Paolo Molaro wrote:
>On 09/04/01 Uri Guttman wrote:
> > does it really matter about comprehension? this is not going to be used
> > by the unwashed masses. a stack machine is easier to describe (hence all
> > the freshman CS projects :), but as dan has said, there isn't
Dan Sugalski <[EMAIL PROTECTED]> wrote
> >my $x = 1;
> >{
> > my $x = 2;
> > delete $MY::{'$x'};
> > print $x;
> > $mysub = sub {$x};
> >}
> >
> >print $mysub->();
> >
> >People seem agreed that print $x should do the equivalent of
> > throw "lexical '$x' no longer in scope
At 01:45 PM 9/5/2001 +0100, Dave Mitchell wrote:
>can I just clarify something about delete:
>
>my $x = 1;
>{
> my $x = 2;
> delete $MY::{'$x'};
> print $x;
> $mysub = sub {$x};
>}
>
>print $mysub->();
>
>People seem agreed that print $x should do the equivalent of
> throw
On 09/04/01 Uri Guttman wrote:
> does it really matter about comprehension? this is not going to be used
> by the unwashed masses. a stack machine is easier to describe (hence all
> the freshman CS projects :), but as dan has said, there isn't much
> mental difference if you have done any serious
can I just clarify something about delete:
my $x = 1;
{
my $x = 2;
delete $MY::{'$x'};
print $x;
$mysub = sub {$x};
}
print $mysub->();
People seem agreed that print $x should do the equivalent of
throw "lexical '$x' no longer in scope"
rather than printing 1, but what s
Garrett Goebel <[EMAIL PROTECTED]> wrote
> From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> > sub Foo::import {
> > my %m = caller(1).{MY}; # or whatever
> > %m{'$x'} = 1;
> > }
...
> > sub f {
> > my $x = 9;
> > use Foo; # does $x become 1, or $x redefined, or runtime
> >
On 09/04/01 Dan Sugalski wrote:
> Regardless, it's the way we're going to go for now. If it turns out to be a
> performance dog then we'll go with a stack-based system. Initial
> indications look pretty good, though.
Care to share some numbers/code for that?
> >You're right that optimization r
On Wed, Sep 05, 2001 at 08:32:36PM +1000, Rick Welykochy wrote:
> Dave Storrs wrote:
> [schnippe]
> > =head3 Generating Code on the Fly
>
> What's this =head3 stuff? My pod processor barfs on it :)
Then update it. :)
Dave Storrs wrote:
[schnippe]
> =head3 Generating Code on the Fly
What's this =head3 stuff? My pod processor barfs on it :)
> Aye, here's the rub.
_
Rick Welykochy || Praxis Services Pty Limited
"One of the main advantages of the 'dot-bomb' downtur
Ken Fox wrote:
> Modifying the caller's environment:
>
> $lexscope = caller().{MY};
> $lexscope{'&die'} = &die_hard;
>
> is especially annoying because it means that I can't
> trust lexical variables anymore.
You think you can trust them now? :-)
The PadWalker module (on CPAN) allows a su
21 matches
Mail list logo
