Merged two commits that I'm pretty sure are about the same issue.
On Tue, 22 Sep 2015 18:09:54 -0700, larry wrote:
> 18:00 < TimToady> m: my @v := [1, 2]; my \step1 = 8 X* ^4; my \step2 = @v
> X+> step1; say step2 X% 256;
> 18:00 <+camelia> rakudo-moar 631ac4: OUTPUT«===SORRY!===Cannot invoke thi
# New Ticket Created by Larry Wall
# Please include the string: [perl #126139]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126139 >
18:00 < TimToady> m: my @v := [1, 2]; my \step1 = 8 X* ^4; my \step2 = @v
X+> step1; say st
structures are subject to change over time; it is therefore erroneous
to pass junctions to any control construct that is not implemented via
as a normal single or multi dispatch. In particular, threading
junctions through conditionals correctly could involve continuations,
which are almost but n
Andrew Whitworth wrote:
> The issue mentioned in the Synopses is that junctions autothread, and
> autothreading in a conditional could potentially create multiple
> threads of execution, all of which are taking different execution
> paths. At some point, to bring it all back together again, the var
l single or multi dispatch. In particular, threading
> junctions through conditionals correctly could involve continuations,
> which are almost but not quite mandated in Perl 6.0.0."
> What is a continuation?
Continuation here is meant in the most generic sense, which is:
"The
re subject to change over time; it is therefore erroneous
>> to pass junctions to any control construct that is not implemented via
>> as a normal single or multi dispatch. In particular, threading
>> junctions through conditionals correctly could involve continuations,
>>
a normal single or multi dispatch. In particular, threading
junctions through conditionals correctly could involve continuations,
which are almost but not quite mandated in Perl 6.0.0."
What is a continuation?
<http://en.wikipedia.org/wiki/Continuation>
Early on, Perl 6 discussio
hreading
junctions through conditionals correctly could involve continuations,
which are almost but not quite mandated in Perl 6.0.0."
What is a continuation?
--
Jonathan "Dataweaver" Lang
hen collecting continuations.
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Mon, 2 Oct 2006 20:54:22 -0400
This weekend's project (committed as r14830) makes continuations
capture the dynamic environment so that they can restore it properly on
invocation. This makes it possible for multiple conti
At 20:54 02/10/2006 -0400, Bob Rogers wrote:
This weekend's project (committed as r14830) makes continuations
capture the dynamic environment so that they can restore it properly on
invocation. This makes it possible for multiple continuations to
coexist that return to different environ
This weekend's project (committed as r14830) makes continuations
capture the dynamic environment so that they can restore it properly on
invocation. This makes it possible for multiple continuations to
coexist that return to different environments in the same context.
One word of ca
Am Samstag, 12. August 2006 17:55 schrieb Bob Rogers:
>From: Leopold Toetsch <[EMAIL PROTECTED]>
>See "Method Overloading and GC Issues" in Cfunc.pod. The only way
>IMHO to avoid this problem is to run GC at "safe" points at the
>runloop level . . .
>
> Had you considered keeping t
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 14:00:19 +0200
The continuation barrier is only one nastyness of inferior runloops. The
second problem with it is that it heavily influences the guts of garbage
collection . . .
See "Method Overloading and GC Issu
eed_GC", allocate more objects and proceed.
This would have also the advantage, that no pointers (e.g. str->strstart)
would move under C code.
Back to continuations.
>2. Eliminate inferior runloops. This is much harder, as it involves
> rewriting much code, though the attache
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Sun, 6 Aug 2006 11:20:08 -0400
Notes on the POC:
. . . It doesn't quite work, apparently because set_retval gives up
too soon, and so set_s_p always sets the result to a null string.
I figured this out in the process of implementing print
Bob Rogers wrote:
There are two broad solutions:
1. Restrict continuations to move only "outward", which makes it
unnecessary to restart inferior runloops. This may not be as bad as it
seems, as most of the languages I can think of can be implemented using
only outward
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Tue, 8 Aug 2006 19:43:31 +0200
Am Sonntag, 6. August 2006 17:20 schrieb Bob Rogers:
[ a much more detailed answer will follow ]
> ? ?The problem is that inferior runloops cannot be re-entered via
> continuation. ?
C is an exce
Am Sonntag, 6. August 2006 17:20 schrieb Bob Rogers:
[ a much more detailed answer will follow ]
> The problem is that inferior runloops cannot be re-entered via
> continuation.
C is an excellent example for the POC. I've a first question
though: assuming that we might want to eliminate in
restarting
the abandoned inferior runloop. This problem also affects coroutines,
which have an implementation similar to continuations.
So the crux of the problem is that the C code that implements the op
has state that cannot be captured by a continuation. Normally, the
entire state of the c
ks?
In what follows, I will speak of these collectively as the "dynamic
state stack", with the understanding that it may need to be pluralized.
(And the further understanding that continuations and coroutines can
make it branch, just like the Parrot_Context => RetContinuation "sta
rious flaw: It leaves the new binding in effect if
executing the rest of the block causes a nonlocal exit. Throwing can be
dealt with by establishing an error handler that reinstates the old
value and rethrows, but this doesn't begin to address continuations, not
to mention coroutines, which
Maybe someone can "translate" this:
http://citeseer.ist.psu.edu/651433.html
to parrot's usage (and troubles) of continuations.
leo
on of continuations I've posted this idea here:
http://xrl.us/gbai
+ never have unused registers
+ no need for a register allocator
This is simplified. We'd need a register allocator for temporary
variables. But it's true that all the register allocation troubles we
now have with l
I hope that no one misunderstands when I say this. It is not meant to be a
criticism, but rather it is my understanding of the problem, put very
directly. I may be wrong, and in many ways, I hope am.
There is a fundamental flaw in the Parrot architecture. In it's current
form, continua
All~
On 6/3/05, Bill Coffman <[EMAIL PROTECTED]> wrote:
>
> There are several threads in the parrot mailing list that discuss the
> continuations problem. I hoped to be able to address parrot register
> allocator again, at some point, but it could be a while before I get to
&
On Fri, Apr 22, 2005 at 09:32:55AM -0700, Larry Wall wrote:
Thank you for your detailled answer. I still don't get what you mean
by "[] pattern matching arguments".
Do you mean smart pattern matching on composite values?
>
> A lot of features are making it into Perl 6 that have historically
functional features will make it
: into Perl6. I know we already got currying.
A lot of features are making it into Perl 6 that have historically been
associated with "functional" programming. Off the top of my head:
currying
continuations
tail recursion
laziness
a
On Fri, Apr 22, 2005 at 08:13:58PM +0200, Stéphane Payrard wrote:
> On Fri, Apr 22, 2005 at 09:32:55AM -0700, Larry Wall wrote:
>
> Thank you for your detailled answer. I still don't get what you mean
> by "[] pattern matching arguments".
> Do you mean smart pattern matching on composite value
Hi,
I am making a presentation about Perl6 this week end. My point will
be: the next generation of applicative languages will be scripting
languages because they have come of age.
Alternatives don't cut it anymore. Indeed C and C++ are memory
allocation nightmare; Java and C# don't have read-ev
On Thu, 21 Apr 2005 08:36:28 -0700, [EMAIL PROTECTED] (Larry Wall) wrote:
>
> Hmm, maybe that's not such a bad policy. I wonder what other "dangerous"
> modules we might have. Ada had UNCHECKED_TYPE_CONVERSION, for instance.
>
How about
use RE_EVAL; # or should that be REALLY_EVIL?
>
On Thu, Apr 21, 2005 at 04:30:07PM +0300, wolverian wrote:
: On Tue, Apr 12, 2005 at 04:17:56AM -0700, Larry Wall wrote:
: > We'll make continuations available in Perl for people who ask for
: > them specially, but we're not going to leave them sitting out in the
: > open where
On Tue, Apr 12, 2005 at 04:17:56AM -0700, Larry Wall wrote:
> We'll make continuations available in Perl for people who ask for
> them specially, but we're not going to leave them sitting out in the
> open where some poor benighted pilgrim might trip over them unawares.
Sorry f
I'm thinking the
> : >> answer to your question is yes.
> : >
> : > Yes. I want to know how Perl 6 exposes continuations, and how to get one
> : > for, say, the current lexical scope, and if it has a method on it that
> : > lets me evaluate code in that cont
ndering about. I'm sorry I was so unclear.
: >
: >> Can you tell me what your idea of a "scope" is? I'm thinking a
: >> continuation, and if that is what you are thinking, I'm thinking the
: >> answer to your question is yes.
: >
: > Yes. I want
l me what your idea of a "scope" is? I'm thinking a
>> continuation, and if that is what you are thinking, I'm thinking the
>> answer to your question is yes.
>
> Yes. I want to know how Perl 6 exposes continuations, and how to get one
> for, say, the current
tinuation, and if that is what you are thinking, I'm thinking the
> answer to your question is yes.
Yes. I want to know how Perl 6 exposes continuations, and how to get one
for, say, the current lexical scope, and if it has a method on it that
lets me evaluate code in that context
'm looking for a way to refer to scopes
programmatically. I'm also asking if they are continuations, or blocks,
or coderefs, or are those all the same?
The two things you mention are effects of being able to refer to scopes
in such a fashion. I do want both, but the real question isn
efs/scopes continuations? Should .eval be a method
in Continuation?
I'm having a bit of trouble following you, but I can tell you that the VM
portion
treats continuations as well as lexical scopes or pads as first class Parrot
objects (or PMCs).
I cannot say how much Perl6 will expose to
On Fri, Apr 08, 2005 at 05:03:11PM +0300, wolverian wrote:
Hi wolverian,
> one day a friend asked if Perl 5 had a REPL facility.
> (Read-Eval-Print-Loop). I told him it has perl -de0, which is different
> [...]
> In Perl 6, the generic solution to fix this (if one wants to fix it)
> seems, to me,
uld be a method on coderefs
or blocks. Is there a difference between the two? I always hated this
about Ruby; there seems to be no practical value to the separation.
Also, are blocks/coderefs/scopes continuations? Should .eval be a method
in Continuation?
Thanks,
--
wolverian
signature.
I would like to do my own preemptive multitasking within a
single-threaded application.
When a timer fires, I'd like to:
1. suspend the current computation
2. put it on the back of a work queue
3. resume the lambda on the top of the work queue.
Will Parrot facilitate this? Thank you for insight
Bill Coffman <[EMAIL PROTECTED]> wrote:
>> two possible interferences of different kinds, with additional coding
>> overhead ...
> ... What makes it a
> little complicated is how do these "ubiquetous" symbols interact with
> the non-ubuiquitous? Those arcs are needed for this.
Yes that's what
Chromatic <[EMAIL PROTECTED]> wrote:
> 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).
Well, having just a short look a
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
get a distinct storage. When f
would only need to copy the data when
> invoking a full continuation
That doesn't work. If you create a real continuation all continuations
up the call chain have to be real continuations. And copying or not
imposes different semantics on register usage.
leo
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
rence graph is effected.
This brings up the possibility of non-volatile symbols that cross subs
that are garanteed *not* to invoke continuations. Those would not
necessarily be part of the clique, but would be non-volatile (forced
into the upper half of registers). The register allocator could
handl
for every invocation.
With what I am proposing we would only need to copy the data when
invoking a full continuation (so that the full continuation can be
invoked again later without disturbing its registers). Invoking
return continuations would be exactly the same as it is now. Thus you
only p
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 when the continuation was taken
hanges would be low, even JIT works with just
> s/ctx\.bp/ctp/g
I meant it at the C level. This feels to me like a fairly major
internal change. Thus, I am a little surprised that the impact would
be as low as you claim. But you are definitely the authority on that.
> > ... Right now
source changes would be low, even JIT works with just
s/ctx\.bp/ctp/g
... Right now 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
inuation restores the context it captured, i.e. at the place,
> where it was created. This is true for all continuations. Inside the
> context there is a *pointer* to a register frame, which is therefore
> restored too.
>
> The effect of taking a continuation is therefore to restore r
new register frame, that subs register
frame pointer in the context points to these fresh registers.
A continuation restores the context it captured, i.e. at the place,
where it was created. This is true for all continuations. Inside the
context there is a *pointer* to a register frame, which is
Dan~
On Tue, 16 Nov 2004 16:24:06 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> We could, but it would be wrong. Hell, it's arguably wrong for return
> continuations to do so, and it wouldn't be unreasonable to argue that
> I and N register contents are guaranteed cru
ntinuation preserves the frame (the mapping from logical
>> >> >variables to their values), but not the values of those
variables at
>> >> >the time the continuation was created.
>> >>
>> >> This is one of the fundamental properties o
te:
> >> >> >The continuation preserves the frame (the mapping from logical
> >> >> >variables to their values), but not the values of those variables at
> >> >> >the time the continuation was created.
> >> >>
> >>
At 10:32 AM -0800 11/16/04, Jeff Clites wrote:
>> >The continuation preserves the frame (the mapping from logical
>> >variables to their values), but not the values of those variables at
>> >the time the continuation was created.
>>
>> This is one of t
AM -0800 11/16/04, Jeff Clites wrote:
> >> >The continuation preserves the frame (the mapping from logical
> >> >variables to their values), but not the values of those variables at
> >> >the time the continuation was created.
> >>
> >> This is one
ues of those variables at
>the time the continuation was created.
This is one of the fundamental properties of continuations, but it
does throw people. And it's why register contents have to be thrown
away when a continuation is invoked, since the registers have values,
and continua
t;the time the continuation was created.
>
> This is one of the fundamental properties of continuations, but it
> does throw people. And it's why register contents have to be thrown
> away when a continuation is invoked, since the registers have values,
> and continuations don
Jeff Clites <[EMAIL PROTECTED]> wrote:
> sub B
> {
> a = 1
> foo()
> print a
> b = 2
> return b
> }
> If something called by foo() captures a continuation, and something
> invokes it after B() returns, then there's a hidden branch, in effect,
> from the return to the
At 10:32 AM -0800 11/16/04, Jeff Clites wrote:
The continuation preserves the frame (the mapping from logical
variables to their values), but not the values of those variables at
the time the continuation was created.
This is one of the fundamental properties of continuations, but it
does throw
On Nov 16, 2004, at 10:03 AM, Matt Fowles wrote:
Since both you and Leo are arguing against me here, it seems like that
I am wrong, but I would like to figure out exactly why I am wrong so
that I can correct my train of thought in the future.
Here's a real example you can play with, if you have Rub
Leo~
On Tue, 16 Nov 2004 18:32:07 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
>
>
> > I disagree with that analysis. Let us consider the actual effect of
> > such an implementation.
> >
> > First iteration
> >
> > i = 0;
> > foo(); #at this point a continuation create
On Nov 15, 2004, at 10:29 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
Picture this call stack:
main --> A --> B --> C --> D --> E
The call from D to E uses the "RESUMEABLE" label, and E stores the
resulting continuation in a global, and everything up to main returns.
Then,
t; >> lp:
> >> >> foo()
> >> >> inc i
> >> >> if i < 10 goto lp
> >>
> >> > There is one thing I am not sure about here. The loop will work
> >> > correctly for each seperate invocation of the appropria
Matt Fowles wrote:
I disagree with that analysis. Let us consider the actual effect of
such an implementation.
First iteration
i = 0;
foo(); #at this point a continuation created capturing i=0, promoted
by Jens and stuff happens
#eventually it is invoked, restoring i=0
i++; #i = 1
foo(); #at this
anymore. Someone e.g. Jens
Rieks[1], discovers that the algoritm is simpler implemented with
continuations. So inside foo() the return continuation of foo() is
copyied, stored elsewhere, passed along to another function, and that
one now suddenly returns via this continuation to your loop
> No. Imagine, foo() is not a simple function anymore. Someone e.g. Jens
> Rieks[1], discovers that the algoritm is simpler implemented with
> continuations. So inside foo() the return continuation of foo() is
> copyied, stored elsewhere, passed along to another function, and that
> o
e about here. The loop will work
> correctly for each seperate invocation of the appropriate
> continuation.
No. Imagine, foo() is not a simple function anymore. Someone e.g. Jens
Rieks[1], discovers that the algoritm is simpler implemented with
continuations. So inside foo() the return continu
Leo~
On Tue, 16 Nov 2004 09:23:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles <[EMAIL PROTECTED]> wrote:
>
> [ continuations should restore registers ]
>
> > I am sorry, but I don't understand what you are trying to say here.
>
Matt Fowles <[EMAIL PROTECTED]> wrote:
[ continuations should restore registers ]
> I am sorry, but I don't understand what you are trying to say here.
> Would you mind rewording it for me?
Imagine a simple loop:
i = 0
lp:
foo()
inc i
if i < 10 goto lp
On Mon, 15 Nov 2004 17:19:01 -0500, Matt Fowles <[EMAIL PROTECTED]> wrote:
> Which gives me an evil idea. We could allow bytecode to specify that
> it wanted to start taking full continuations everywhere, but that
> these would never be used below it on the callstack. Thus the
ence of Continuation, which, by creating a loop from your code,
> start preserving your scalar data types.
I am sorry, but I don't understand what you are trying to say here.
Would you mind rewording it for me?
> I didn't mention the runtime impact yet. You said already that it&#x
Jeff Clites <[EMAIL PROTECTED]> wrote:
> Picture this call stack:
> main --> A --> B --> C --> D --> E
> The call from D to E uses the "RESUMEABLE" label, and E stores the
> resulting continuation in a global, and everything up to main returns.
> Then, main invokes the continuation, and we
At 9:16 AM -0800 11/15/04, Larry Wall wrote:
On Mon, Nov 15, 2004 at 09:51:58AM +0100, Leopold Toetsch wrote:
: Yes, as said I'm fine too with that. Perl/Python will do that anyway.
: But what about other languages? Are we forcing these to be as dynamic as
: the primary HLL targets?
In Perl 6, any
On Mon, Nov 15, 2004 at 09:51:58AM +0100, Leopold Toetsch wrote:
: Yes, as said I'm fine too with that. Perl/Python will do that anyway.
: But what about other languages? Are we forcing these to be as dynamic as
: the primary HLL targets?
In Perl 6, any assumptions that cause inefficiency should b
ays for maximum locality (so that they can be sized
independently), or we need to be able to size the register frames
independently for the 4 types. (I realize that currently lexicals must
be PMCs, but it seems we have the same issue with other reg. types.)
... That is, if you have 100
local variables whose
Matt Fowles <[EMAIL PROTECTED]> wrote:
> All~
> ... When a full continuation is invoked it
> *copies* its contenxt into place (thus it can be invoked multiple
> times and it will always have its original context).
If you mean by "context" C then yes, this is what
All~
I think I may know a way around this problem. You will have to bear
with me for a moment as I am not entirely used to speaking in terms of
continuations (I find a similar difficulty in speaking about Math, but
at least I have a commonly accepted lexicon for that ;-).
The view from 10,000
dy shows the problem:
Yes, that one is reflecting it.
> a = 1
> foo()
> print a
> b = 10
> return b
> It would seem (w/o continuations) that b should be able to re-use a's
> register, but if it does then we'll print 10 instead of 1 &quo
ck
catch_label:
# catch block
The try block is starting exactly at this point, where the exception
handler gets pushed onto the contol stack. By connecting the C
opcode to the catch block with an edge in the CFG, we could easily
prevent the reuse of registers located in front of the try block.
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Jeff Clites writes:
>> a = 1
>> foo()
>> print a
>> b = 10
>> return b
>>
>> It would seem (w/o continuations) that b should be able to re-use a's
>> register, but i
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 5:53 PM +0100 11/13/04, Leopold Toetsch wrote:
>>As the analysis of test errors of the new reigster allocator has
>>shown, we have a problem WRT register allocation. This problem isn't
>>new, but as the allocator is more efficiently reusing registers (or
fraid I'm missing something.) It seems
> that even this function body shows the problem:
>
> a = 1
> foo()
> print a
> b = 10
> return b
>
> It would seem (w/o continuations) that b should be able to re-use a's
> register, but if it do
rint a
b = 10
return b
It would seem (w/o continuations) that b should be able to re-use a's
register, but if it does then we'll print 10 instead of 1 "the second
time".
So what to do:
1) Extending register frame size ad infinitum and never reuse a Parrot
register will defi
sidered. (1) An exception can happen in a try block, so CFG arcs
need to be added from statements within the try block to the catch.
(2) Continuations, which I don't pretend to understand, can also flow
in previously unconsidered directions. Those arcs need to be added to
the CFG.
Alterna
On Nov 14, 2004, at 1:53 PM, Dan Sugalski wrote:
Since, for example, it's completely reasonable (well, likely at least)
for a called sub to rebind lexicals in its parent
What does that mean, exactly? It seems like that directly contradicts
the meaning of "lexical". For instance, see Larry's comme
At 5:53 PM +0100 11/13/04, Leopold Toetsch wrote:
As the analysis of test errors of the new reigster allocator has
shown, we have a problem WRT register allocation. This problem isn't
new, but as the allocator is more efficiently reusing registers (or
reusing them in a different way) it's expose
At 11:01 PM +0100 11/13/04, Leopold Toetsch wrote:
Matt Fowles <[EMAIL PROTECTED]> wrote:
> I get the feeling that this is equivalent to requiring exception
handlers to be a locally defined closure, which is another way we
could go about this.
Yes. That solves it. OTOH going all along with lexic
line the register allocator happily reuses the register that
arr2 had for $P0. That's totally legal in the absence of continuations.
So it doesn't suffice that the register frame is restored and that
variables are in the same place.
The effect of the continuation is the creation of a lo
call to bar, and
> that of c and d would end at the call to baz, but due to continuations,
> the call to zoo might resume at the op right after the call to foo
> (since the continuation created when calling foo may have been
> captured), so a,b,c,d have to persist at least until the l
On Nov 13, 2004, at 2:46 PM, Matt Fowles wrote:
On Sat, 13 Nov 2004 14:08:12 -0800, Jeff Clites <[EMAIL PROTECTED]>
wrote:
That's oversimplifying a bit, but I feel like those are the core
issues
(stemming from the observation of Leo's that continuations in effect
give all vari
Jeff~
On Sat, 13 Nov 2004 14:08:12 -0800, Jeff Clites <[EMAIL PROTECTED]> wrote:
> That's oversimplifying a bit, but I feel like those are the core issues
> (stemming from the observation of Leo's that continuations in effect
> give all variables a lifetime that extends
nts.
That's oversimplifying a bit, but I feel like those are the core issues
(stemming from the observation of Leo's that continuations in effect
give all variables a lifetime that extends to their entire block, in
most cases).
JEff
Matt Fowles <[EMAIL PROTECTED]> wrote:
> I like the idea of mandating lexicals vars. This would also eliminate
> the need for spilling (I think), as the register allocator would only
> need to refetch the lexical rather than save it off somewhere to be
> restored later.
There are two issues: yes
All~
On Sat, 13 Nov 2004 10:52:38 -0800, Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Nov 13, 2004, at 8:53 AM, Leopold Toetsch wrote:
> > We'd have just to force using lexicals for all vars
>
> Having variable-size register sets would solve this, since you could
> have fixed assignments of variab
On Nov 13, 2004, at 8:53 AM, Leopold Toetsch wrote:
2) Continuations (t/op/gc_13.imc [Hi Piers])
Again we have a hidden branch done by a Continuation, or better a
loop. The control flow of the main program is basically represented by
this conventional code fragment:
arr1=[...]; arr2
r isn't to blame, that looks really fine.
We have two kinds of problems one with exceptions and one with
continuations. As exceptions are continuations, we could also define it
as the same problem. Anyway, the usage of exceptions is a bit different.
Catch blocks are local labels only AFAIK in HLL
1 - 100 of 332 matches
Mail list logo
