# New Ticket Created by chromatic
# Please include the string: [perl #60652]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60652 >
Several tests in t/op/lexicals.t fail when run as PBC (or with parrot -r):
t/op/lexic
2008/9/24 Patrick R. Michaud <[EMAIL PROTECTED]>:
> On Wed, Sep 24, 2008 at 12:09:37PM +0200, François Perrad wrote:
>> Currently, the bigger issue in Lua on Parrot is lexical or upvalue in
>> Lua jargon (the reason for Lua on Parrot is not really Lua).
>> The following Lua code doesn't give the ex
On Wed, Sep 24, 2008 at 11:31 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 24, 2008 at 10:05:25PM +0200, Stéphane Payrard wrote:
>> One of parrot current limitation is that eval is always a closure.
>> When using rakudo interactively, one want to introduce new
>> lexical variable
Tom Christiansen:
> > Don't we have to solve all this to get the Perl 6 debugger
> > working anyway?
>
> Although I'm unsure why that might be, I also recognize the possibility
> that there may well exist hypothetical documents, unread by me, which
> mandate some scenario or behavior wherein the
whether perhaps this *might* not apply to perl6
> and ask that, should this indeed be what's afoot, that I be gently
> enlightened.
As far as I'm aware, there's nothing in the current Perl 6 design
or synopses that indicate that things are substantially different
in this a
prompt mode will need to
>>>> be able to maintain it's own dynamic lexical pad (i.e., a
>>>> DynLexPad) and have some way of extracting any lexical changes
>>>> from whatever code string it evaluates.
>>> I wouldn't call them DynLexPad or l
t; directly and not just their register indices. Doing so would require
> that the :outer sub also do store_lex and find_lex on lexical variables,
> and not just the inner ones. (That could be a drawback or a feature,
> depending on your point of view.)
Given the way that code generation
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Tue, 23 Sep 2008 03:45:37 -0500
I've put together a draft with my ideas and design for
(re-)implementing lexicals in Parrot -- now available at
http://www.pmichaud.com/perl6/lexical.txt .
It's a
exical changes from whatever code string
> > > it evaluates.
> >
> > I wouldn't call them DynLexPad or lexicals at all, I would call them
> > just globals. lexvars could shadow them though, but this a user
> > problem then.
>
> This approach might expose so
7;. In
> > particular, the interactive prompt mode will need to be able to
> > maintain it's own dynamic lexical pad (i.e., a DynLexPad) and have
> > some way of extracting any lexical changes from whatever code string
> > it evaluates.
>
> I wouldn't call them
> maintain it's own dynamic lexical pad (i.e., a DynLexPad) and have
> some way of extracting any lexical changes from whatever code string
> it evaluates.
I wouldn't call them DynLexPad or lexicals at all, I would call them
just globals.
lexvars could shadow them though, but t
On Wed, Sep 24, 2008 at 10:05:25PM +0200, Stéphane Payrard wrote:
> One of parrot current limitation is that eval is always a closure.
> When using rakudo interactively, one want to introduce new
> lexical variable that are not lost when accessing them from the
> next prompt.
> Pugs gets that rig
On Tue, Sep 23, 2008 at 03:45:37AM -0500, Patrick R. Michaud wrote:
> I've put together a draft with my ideas and design for
> (re-)implementing lexicals in Parrot -- now available at
> http://www.pmichaud.com/perl6/lexical.txt .
Earlier today chromatic asked about recursion in
One of parrot current limitation is that eval is always a closure.
When using rakudo interactively, one want to introduce new lexical variable that
are not lost when accessing them from the next prompt.
Pugs gets that right.
My take on the subject 8 years ago!
I don't know how that interacts with
On Wed, Sep 24, 2008 at 12:09:37PM +0200, François Perrad wrote:
> Currently, the bigger issue in Lua on Parrot is lexical or upvalue in
> Lua jargon (the reason for Lua on Parrot is not really Lua).
> The following Lua code doesn't give the expected result (from
> languages/lua/t/closure.t) :
Patrick R. Michaud a écrit :
I've put together a draft with my ideas and design for
(re-)implementing lexicals in Parrot -- now available at
http://www.pmichaud.com/perl6/lexical.txt .
It's a first draft and might be a bit confusing in places,
but overall I think it's a far clea
I've put together a draft with my ideas and design for
(re-)implementing lexicals in Parrot -- now available at
http://www.pmichaud.com/perl6/lexical.txt .
It's a first draft and might be a bit confusing in places,
but overall I think it's a far cleaner design than the
current imp
On Sun, Mar 09, 2008 at 04:17:51PM -0400, Bob Rogers wrote:
> From: Klaas-Jan Stol (via RT) <[EMAIL PROTECTED]>
> : when running a language in interactive mode, and you declare a local
> : variable, then this local variable cannot be accessed afterwards.
>
> That's it exactly. A general solutio
On Tue, Apr 1, 2008 at 2:37 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 01, 2008 at 01:23:38PM +0200, Klaas-Jan Stol wrote:
> > in the exception handler, a new Undef is created in $P0. When leaving
> > this line, this code won't work. When commenting out this line, it
> > wil
On Tue, Apr 01, 2008 at 01:23:38PM +0200, Klaas-Jan Stol wrote:
> in the exception handler, a new Undef is created in $P0. When leaving
> this line, this code won't work. When commenting out this line, it
> will print "hi", as expected.
> I don't get that, because, 3 lines later, a new object is st
I'm a bit confused on how lexicals are supposed to work. Below is a
simple example, which looks more or less on code generated by PCT for
a try/catch statement.
in the exception handler, a new Undef is created in $P0. When leaving
this line, this code won't work. When commenting out thi
From: Klaas-Jan Stol (via RT) <[EMAIL PROTECTED]>
Date: Sun, 09 Mar 2008 09:43:02 -0700
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #51560]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Displ
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #51560]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51560 >
hi,
when running a language in interactive mode, and you declare a local
variable, th
Yep, this is the issue that I wrote about a couple of days ago. If
you take a look at the code though, there is a point where the block
for bar is being made into a closure. Take a look at sub _block14:
.sub "_block14" :outer("_block12")
get_global $P20, "_block15"
newclosure $P20, $P2
On Wed, Feb 06, 2008 at 03:33:14PM +0100, Klaas-Jan Stol wrote:
> function foo()
>
> local a = 2
>
> function bar()
> print(a)
> end
> end
>
> foo()
> bar()
>
> What happens here is, a function foo is defined, in which a local var. "a"
> is initialized to the value "2". Ano
Hi,
I have trouble understanding how lexicals work in the code that is generated
by PCT.
Consider the following Lua snippet:
function foo()
local a = 2
function bar()
print(a)
end
end
foo()
bar()
What happens here is, a function foo is defined, in which a local var. &q
:outer("foo") now basically works, there is also a new Sub method
C.
There is one limitation though: the subroutine referenced by :outer must
be already compiled, that is: it must be in the same sourcefile [1] and
it's source code has to appear before the sub referencing it [2].
[1] can for
Klaas-Jan Stol wrote:
maybe I misunderstand, but does the above mean that lexicals are stored
in registers, instead of storing them in scratchpads? (with lexicals
being local variables in a function, with the addition of being also
accessible from nested functions)
The storage of lexicals
Matt Diephouse (via RT) wrote:
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #36623]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36623 >
There's currently no way to delete a global or a lex
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #36623]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36623 >
There's currently no way to delete a global or a lexical.
mdiep: you should be
At 7:20 PM +0100 11/30/04, Thomas Seiler wrote:
At Tue 30 Nov 6:22pm, Dan Sugalski wrote:
Architecture changes aren't an option we're entertaining until after we're
functionally complete.
Just would like to ask a related question:
Is a change that invalidates an existing precompiled bytecode but
At Tue 30 Nov 6:22pm, Dan Sugalski wrote:
> Architecture changes aren't an option we're entertaining until after we're
> functionally complete.
Just would like to ask a related question:
Is a change that invalidates an existing precompiled bytecode but not
the source code of it
considered as an ar
At 5:30 PM +0100 11/30/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 9:15 PM +0100 11/23/04, Leopold Toetsch wrote:
Below inline/attached are some thoughts WRT the subject.
leo
Lexicals, continuations, and register allocation
1) Recent discussions have shown t
Leo~
On Tue, 30 Nov 2004 17:30:43 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 9:15 PM +0100 11/23/04, Leopold Toetsch wrote:
> >>Below inline/attached are some thoughts WRT the subject.
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:15 PM +0100 11/23/04, Leopold Toetsch wrote:
>>Below inline/attached are some thoughts WRT the subject.
>>
>>leo
>>
>>
>>Lexicals, continuations, and register allocation
>>
>>1) Recent discus
Dan~
On Tue, 30 Nov 2004 10:22:29 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:15 PM +0100 11/23/04, Leopold Toetsch wrote:
>
>
> >Below inline/attached are some thoughts WRT the subject.
> >
> >leo
> >
> >
> >Lexicals, cont
At 9:15 PM +0100 11/23/04, Leopold Toetsch wrote:
Below inline/attached are some thoughts WRT the subject.
leo
Lexicals, continuations, and register allocation
1) Recent discussions have shown that we obviously can't handle all
the side effects of continuations correctly. Reusing preserved
are needed for this.
Yes that's what I've already stated above ;)
> It was Larry Wall who suggested the pragma in the long thread,
Yes I've bookmarked it. But a pragma doesn't solve outside effects of
libraries that just capture the continuation under your hood.
And - aga
the time, except for such platform stuff. I test
on two platforms, 3 computers. Tests are currently not passing due to
obvious violations of the recent pdd03 changes.
t/op/gc_13.imc would still fail because of continuation and register
allocation, it's just using lexicals now.
> ... Then it must
Matt Fowles <[EMAIL PROTECTED]> wrote:
> On Wed, 24 Nov 2004 17:25:05 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> a = b + c + foo()
> I am not sure that they are as rare as you think.
Does it matter? They are no lexicals, you can't refetch them. So they
On Wed, 2004-11-24 at 15:04 +, Nicholas Clark wrote:
> Quite a lot of us would just like parrot COMPLETE and CORRECT before
> starting to put a lot of effort into how fast it is.
I'd settle for it compiling (#32514). If not for the broken build, I'd
have poked at three or four small TODO ite
On Wed, 24 Nov 2004 09:39:27 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Bill Coffman wrote:
> > On Tue, 23 Nov 2004 23:26:39 +0100, Leopold Toetsch <[EMAIL PROTECTED]>
> > wrote:
>
> > Keep in mind that you don't actually have to add all those CFG edges.
> > You already know precisely th
a side effect it will make Dan's evils subs compile, because
> >> long-lived lexicals already have their storage aka register. Only temps
> >> need a register allocated.
>
> > What happens to temps that need to cross function calls in your scheme?
>
> These would go
Matt Fowles <[EMAIL PROTECTED]> wrote:
> Leo~
> On Wed, 24 Nov 2004 16:42:31 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> And as a side effect it will make Dan's evils subs compile, because
>> long-lived lexicals already have their storage aka regi
Leo~
On Wed, 24 Nov 2004 16:42:31 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> And as a side effect it will make Dan's evils subs compile, because
> long-lived lexicals already have their storage aka register. Only temps
> need a register allocated.
What happens t
ECT before
> starting to put a lot of effort into how fast it is.
Yes. Obviously my posting proposes a solution for the current incorrect
behavior of continuations in combination with register re-allocation.
And as a side effect it will make Dan's evils subs compile, because
long-lived lex
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> I'm probably going to get shot for suggesting this, but if each interpreter
> has a count of the number of full continuations invoked (ie non-return
> continuations), then I think that we can know when we *haven't*.
Nobody gets shot - and - interesting
p | interpreter state|
>>+-+--+
>> |
>> ++
>>|
>> +--+-+---+--+
>> | prev | ctx | lexicals | volatiles|
>> +--+-+---+--+
>>| p a r r o t r e g i s t e r s |
> A very strong architecture for sure.
> > + no lex
On Wed, Nov 24, 2004 at 09:45:27AM -0500, Ken Fox wrote:
>As long as an architecture change is on the
> table, might as well make it a doozy.
Quite a lot of us would just like parrot COMPLETE and CORRECT before
starting to put a lot of effort into how fast it is.
PLEASE c
Leopold Toetsch wrote:
+-+--+
| ctp | interpreter state|
+-+--+
|
++
|
+--+-+---+--+
| prev | ctx | lexicals | volatiles
On Wed, Nov 24, 2004 at 09:39:27AM +0100, Leopold Toetsch wrote:
> Bill Coffman wrote:
> >Another interesting thing about this problem is that these new CFG
> >edges are rarely, or at least with low probability, ever travelled.
>
> We just don't know it, rare or not doesn't matter.
I'm probably
Leopold Toetsch wrote:
Sure. But I've no confirmation of a compiler writer that its possible.
Annotating PIR can only work for nested closures. If libraries are
involved you are out of luck.
And we have such code already in library/Streams/Sub.imc.
I've been thinking of what could be implemented
Bill Coffman wrote:
On Tue, 23 Nov 2004 23:26:39 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Keep in mind that you don't actually have to add all those CFG edges.
You already know precisely the effects of adding them. All
non-volatile symbols (those crossing subs that might make continuati
Matt Fowles <[EMAIL PROTECTED]> wrote:
> Leo~
> On Wed, 24 Nov 2004 04:55:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> I've clearly stated that lexicals aka non-volatiles have distinct
>> registers.
> Thus for these large subs, won't this be
On Wed, 24 Nov 2004 04:55:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles <[EMAIL PROTECTED]> wrote:
> > ... However, if a continuation restores registers to the data they
> > had when the continuation was taken, then all of the registers will
> > contain the things that exactly
On Tue, 23 Nov 2004 23:26:39 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
>
> > Have we seen that this actually destroys us? Meaning, if we add the
> > extra CFG arcs, do we start spilling like mad? If not, this is much
> > ado about nothing.
>
> Please first have a lo
Leo~
On Wed, 24 Nov 2004 04:55:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles <[EMAIL PROTECTED]> wrote:
>
> > Won't your approach put every one of those things in its own register?
>
> I've clearly stated that lexicals aka non-volati
Matt Fowles <[EMAIL PROTECTED]> wrote:
> Won't your approach put every one of those things in its own register?
I've clearly stated that lexicals aka non-volatiles have distinct
registers.
> ... However, if a continuation restores registers to the data they
> had
we guarantee that return continuations restore all
> > non-volatile registers. If we extend that guarantee to all
> > continuations, everything would just work with the caveat that changes
> > to value registers (as opposed to reference registers) are lost. This
> > is n
opposed to reference registers) are lost. This
is not a real loss though because refetch all lexicals already
requires backing store for I and N registers.
You are missing the point. It's not a question of preserving, it's
register re-using. And forcing all I and N registers into lexical PMCs
Leo~
On Tue, 23 Nov 2004 21:15:33 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Below inline/attached are some thoughts WRT the subject.
>
> leo
>
>
> Lexicals, continuations, and register allocation
>
> 1) Recent discussions have shown that we obvious
Below inline/attached are some thoughts WRT the subject.
leo
Lexicals, continuations, and register allocation
1) Recent discussions have shown that we obviously can't handle all
the side effects of continuations correctly. Reusing preserved
(non-volatile) registers after a call isn't po
On Mon, 2004-05-17 at 19:40, TOGoS wrote:
> This patch adds an extensive answer to "what's with
> lexical pads?", and simple answers to "how do i call a
> function?". It also adds several questions regarding
> object methods and attributes, and manages to answer
> one of them.
Thanks, I'll apply
# New Ticket Created by TOGoS
# Please include the string: [perl #29674]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29674 >
This patch adds an extensive answer to "what's with
lexical pads?", and simple answers to "h
On Mon, 16 Dec 2002, Leopold Toetsch wrote:
> Simon Glover wrote:
>
> > I've been looking into the cause of these failures, and it seems to be
> > yet another GC bug (or more likely another symptom of the same
> > underlying bug).
> >
> > The problem in this case is in scratchpad_new (in sub.
Simon Glover wrote:
I've been looking into the cause of these failures, and it seems to be
yet another GC bug (or more likely another symptom of the same
underlying bug).
The problem in this case is in scratchpad_new (in sub.c). This creates a
new Scratchpad PMC, and subsequently also creat
Simon Glover wrote:
I've been looking into the cause of these failures, and it seems to be
yet another GC bug (or more likely another symptom of the same
underlying bug).
The problem in this case is in scratchpad_new (in sub.c). This creates a
new Scratchpad PMC, and subsequently also creat
I've been looking into the cause of these failures, and it seems to be
yet another GC bug (or more likely another symptom of the same
underlying bug).
The problem in this case is in scratchpad_new (in sub.c). This creates a
new Scratchpad PMC, and subsequently also creates two new lists (one
[EMAIL PROTECTED] wrote:
... this seemed reasonable, but it
doesn't help:
.sub _foo
.local int x
x = 5
.namespace ANON
.local int x
x = 3
print x
.endnamespace ANON
print x
.end
All untested features are b0rken.
I got namespace now running, above snippet be
Leo --
Here's a Jako snippet:
var int x = 5;
{
var int x = 3;
print x;
}
print x
A naiive translation to imcc might be:
.sub _foo
.local int x
x = 5
.local int x
x = 3
print x
print x
.end
but (of course) that leads to an "x already defined" error.
I was hoping
At 4:36 PM -0500 12/3/02, Dan Sugalski wrote:
At 12:05 PM -0800 12/3/02, Jonathan Sillito wrote:
(Would someone like to put the attached file into examples/assembly and
commit it? Also could someone look at the patch in #18419?)
Attached files are in, and I'll go dig up that patch and apply it.
At 12:05 PM -0800 12/3/02, Jonathan Sillito wrote:
The example file has gotten out of date, thanks for pointing this out. The
attached example file fixes this. Also the lexical ops are documented in
core.ops and in the file docs/core_ops.pod which is generated from the
core.ops file at compile tim
header file?
>
> I take it the design of lexicals is still undecided, as
> examples/assembly/lexicals.pasm coughs up errors - ? For now, to make
> things work I'll probably end up (ab)using a hash as a symbol table.
>
> Also the ChangeLog hasn't been updated since 2002
The hash_destroy function is in include/parrot/hash.h but not defined (or
invoked) anywhere. I presume this is because hashes are GC'd, so
hash_destroy can now be removed from the header file?
I take it the design of lexicals is still undecided, as
examples/assembly/lexicals.pasm coug
At 11:50 AM -0700 9/23/02, Jonathan Sillito wrote:
> > -Original Message-
>> From: Piers Cawley [mailto:[EMAIL PROTECTED]]
>> "Jonathan Sillito" <[EMAIL PROTECTED]> writes:
>> > get_counter:
>> > new_pad 1
>>
>> Doesn't this violate the 'caller saves' principle, making it hard to
> -Original Message-
> From: Piers Cawley [mailto:[EMAIL PROTECTED]]
> "Jonathan Sillito" <[EMAIL PROTECTED]> writes:
> > get_counter:
> > new_pad 1
>
> Doesn't this violate the 'caller saves' principle, making it hard to
> do tail call optimization? Would it make sense to move the cre
"Jonathan Sillito" <[EMAIL PROTECTED]> writes:
>> -Original Message-
>> From: Sean O'Rourke [mailto:[EMAIL PROTECTED]]
>>
>> I think I didn't look through the patch queue carefully enough ;). I
>> gather that it's accepted practice (or something like that) to use an
>> array of pointers i
On 17 Sep 2002, Juergen Boemmels wrote:
> You do something like push_pad implicitly in the Sub class, but
> without a corresponding op in core.ops, when you invoke the Sub.
> You also get the current lexical scope implicitly at Sub creation
> time. This may be intentional so that the bytecode cant
"Sean O'Rourke" <[EMAIL PROTECTED]> writes:
> > At the moment I try to use this to get functions working in Scheme. I
> > have something, that is somewhat working in gdb, but not ready yet.
>
> Maybe we need a "pad pumpkin" to avoid these kinds of race conditions.
My actual implementation is a
, Juergen Boemmels wrote:
> I have several questions regarding lexicals.
>
> There is a discrepancy between parrot_assembly.pod and core.ops
> parrot_assembly.pod says that find_lex will return a pointer, where as
> core.ops uses find_lex to retrive a value and store_lex to set this
&g
Hi,
I have several questions regarding lexicals.
There is a discrepancy between parrot_assembly.pod and core.ops
parrot_assembly.pod says that find_lex will return a pointer, where as
core.ops uses find_lex to retrive a value and store_lex to set this
value. Which of this is correct
At 01:43 PM 9/6/2001 -0700, Brent Dax wrote:
>Dan Sugalski:
># At 12:04 PM 9/6/2001 -0700, Brent Dax wrote:
># >In the more general case, however (say, $x*1+$x*2+...$x*65) that's an
># >interesting question. Could we just do some fun stuff with
># lists? What
># >do real CPUs do?
>#
># Real CPUs
Dan Sugalski:
# At 12:04 PM 9/6/2001 -0700, Brent Dax wrote:
# >If foo is an unprototyped function (and thus takes a list in
# P0) we can
# >immediately push the values of those calculations on to the list,
# >something like (in a lame pseudo-assembler that doesn't use the right
# >names for instr
At 12:04 PM 9/6/2001 -0700, Brent Dax wrote:
>If foo is an unprototyped function (and thus takes a list in P0) we can
>immediately push the values of those calculations on to the list,
>something like (in a lame pseudo-assembler that doesn't use the right
>names for instructions):
FWIW, it's:
At 12:34 PM 9/6/2001 -0700, Brent Dax wrote:
>Dan Sugalski:
>...
># new P0, list# New list in P0
># get_lex P1, $x # Find $x
># get_type I0, P1 # Get $x's type
># set_i I1, 1 # Set our loop var
># $10: new P2, I0
Dan Sugalski:
...
# new P0, list# New list in P0
# get_lex P1, $x # Find $x
# get_type I0, P1 # Get $x's type
# set_i I1, 1 # Set our loop var
# $10: new P2, I0 # Get a temp of the same type as $x
#
Dave Mitchell:
# Simon Cozens <[EMAIL PROTECTED]> wrote:
# > On Thu, Sep 06, 2001 at 02:54:29PM +0100, Dave Mitchell wrote:
# > > So I guess I'm asking whether we're abandoning the Perl 5 concept
# > > of a pad full of tmp targets, each hardcoded as the
# target for individual
# > > ops to store t
At 01:21 PM 9/6/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > > Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > > Where do they come from? Leave a plate of milk and cookies on your back
> > > > porch and the Temp PMC Gnomes will bring them. :)
>
> > Bad Dan! No cookie for me.
>
>You aren't foo
Dan Sugalski wrote:
> > Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > Where do they come from? Leave a plate of milk and cookies on your back
> > > porch and the Temp PMC Gnomes will bring them. :)
> Bad Dan! No cookie for me.
You aren't fooling anybody anymore... You might just as well stop the
At 10:45 AM 09-06-2001 -0400, Ken Fox wrote:
>Dave Mitchell wrote:
> > So how does that all work then? What does the parrot assembler for
> >
> > foo($x+1, $x+2, , $x+65)
>
>The arg list will be on the stack. Parrot just allocates new PMCs and
>pushes the PMC on the stack.
>
>I assume it
On Thu, Sep 06, 2001 at 12:13:11PM -0400, Dan Sugalski wrote:
> Hmmm. Yes, in fact it should. That code will end up with a list of 65
> identical scalars in it. Bad Dan! No cookie for me.
Damn. I guess that means we have to write a compiler after all. I was
looking forward to having Dan assemble
At 05:00 PM 9/6/2001 +0100, Dave Mitchell wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > What we're going to do is have a get_temp opcode to fetch temporary PMCs.
> > Where do they come from? Leave a plate of milk and cookies on your back
> > porch and the Temp PMC Gnomes will bring them. :)
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> What we're going to do is have a get_temp opcode to fetch temporary PMCs.
> Where do they come from? Leave a plate of milk and cookies on your back
> porch and the Temp PMC Gnomes will bring them. :)
Ah, things are starting to make sense!
> ne
ery nice if someone were to write something up in pod comparing
>and constrasting pads/lexicals in the context of Perl5 vs. Perl6.
Well, that'll be reasonably tough as we don't have anything running for
perl 6. Yet. ;-)
Dan
--
From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
Subject: pads and lexicals
>
> Dave "confused as always" M.
>
I just wanted to say that I'm really enjoying this pad/lexical thread.
There's a lot of info passing back and forth that I don't believe is clea
At 03:21 PM 9/6/2001 +0100, Dave Mitchell wrote:
>Simon Cozens <[EMAIL PROTECTED]> wrote:
> > On Thu, Sep 06, 2001 at 02:54:29PM +0100, Dave Mitchell wrote:
> > > So I guess I'm asking whether we're abandoning the Perl 5 concept
> > > of a pad full of tmp targets, each hardcoded as the target for
At 10:45 AM 9/6/2001 -0400, Ken Fox wrote:
>Dave Mitchell wrote:
> > So how does that all work then? What does the parrot assembler for
> >
> > foo($x+1, $x+2, , $x+65)
>
>The arg list will be on the stack. Parrot just allocates new PMCs and
>pushes the PMC on the stack.
No, it won't ac
Dave Mitchell wrote:
> So how does that all work then? What does the parrot assembler for
>
> foo($x+1, $x+2, , $x+65)
The arg list will be on the stack. Parrot just allocates new PMCs and
pushes the PMC on the stack.
I assume it will look something like
new_pmc pmc_register[0]
a
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 06, 2001 at 02:54:29PM +0100, Dave Mitchell wrote:
> > So I guess I'm asking whether we're abandoning the Perl 5 concept
> > of a pad full of tmp targets, each hardcoded as the target for individual
> > ops to store their tmp results in.
>
> N
On Thu, Sep 06, 2001 at 02:54:29PM +0100, Dave Mitchell wrote:
> So I guess I'm asking whether we're abandoning the Perl 5 concept
> of a pad full of tmp targets, each hardcoded as the target for individual
> ops to store their tmp results in.
Not entirely; the last thing we want to be doing is c
1 - 100 of 108 matches
Mail list logo
