I've been looking at various Perl6 operators in terms of what their
implementation would look at the Parrot level. Junctions struck me as
possibly highly problematic. The issue is, how would one go about
compiling them at the point when they get passed to a function call as 1
of the parameters.
This is a summary of a private mail conversation between Leo and myself.
No, it didn't start by me forgetting to fix Reply-To when trying to
post follow-up on the list. ;)
Essentially we whipped up a GC scheme for collecting the register stacks
that doesn't make call/cc-using code, well, unusab
[EMAIL PROTECTED] wrote:
Could we have the chunks only hold one frame and avoid much of the
compaction work? If we return to the inderict access mechanism, we
can switch register frames by changing one pointer. But if we keep
the one frame per chunk, we do not need to compact frames, standard
DOD
[EMAIL PROTECTED] wrote:
a) accessing a new register frame and context
b) during DOD/GC
We have to address both areas to get rid of the majority of cache
misses.
ad a)
For each level of recursion, we are allocating a new context structure
and a new register frame. Half of these is coming from the r
Leopold Toetsch wrote:
I believe that you shouldn't litter (i.e. create an immediately
GCable object) on each function call - at least not without
generational collector specifically optimised to work with this.
The problem isn't the object creation per se, but the sweep through
the *whole obje
[EMAIL PROTECTED] wrote:
On Nov 8, 2004, at 11:15 AM, Matt Fowles wrote:
Dan~
On Mon, 8 Nov 2004 13:45:08 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
The calling conventions and code surrounding them will *not* change
now. When all the sub stuff, and the things that depend on it, are
fully speci
Dan Sugalski wrote:
It's also important for people writing these things to take into
account the possibility that their exit actions may potentially be
triggered multiple times, courtesy of the joys of continuations.
Hmm, the first thing to take into the account is that return
continuations can
Dan Sugalski wrote:
Hmm, the first thing to take into the account is that return
continuations can be promoted to the fully blown continuations. This
should affect the handlers in the same way - so exception handlers
could have become arbitrary invokable objects at the point when the
exception
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
[EMAIL PROTECTED] wrote:
I think we have basically 3 choices: support continuations such that
they work correctly in all HLL situations and accept likely poor
performance, or support only escape continuations, or devise a
strategy whereby Parrot itself doesn't provide continuations, but
allows
[EMAIL PROTECTED] wrote:
What this means is that care must be taken when you are writing code
that you expects to be invoked multiple times. However, if you are a
function that on your second invocation returns via the continuation
from you first invocation, you should probably expect to be called
[EMAIL PROTECTED] wrote:
What about multi subs? They can be defined everywhere. Given:
multi sub *foo(A $a, B $b) {...}
Is this something like:
%globals{"foo"} --> MultiSub{"foo_A_B" => Sub, ...}
What about a not so global multi:
multi sub foo(A $a, B $b) {...}
Thanks for clarifying,
leo
Uh
[EMAIL PROTECTED] wrote:
Ok. If you'd really need such random dispatch, it could be done like
this, when I interpret A12 correctly:
sub run_random_bar($x) {
my @meths = WALKMETH($x, :method('bar'));
my $meth = @meths[rand(@meths.elems)];
$meth($x);
}
or even with
my sub bar($x) {...}
[EMAIL PROTECTED] wrote:
pugs too lazy
Miroslav Silovic noticed that closing a file handle in pugs did not
force all the thunks associated with the file. While this was a bug in
pugs, it led to conversation about whether = should be lazy or eager.
Larry thinks that it will be safer
14 matches
Mail list logo
