Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Nov 11, 2004, at 12:59 PM, Leopold Toetsch wrote:
>> As Dan already has outlined a Continuation doesn't have any impact on
>> tail calls (my argument WRT that was wrong)
> I'm confused then. What from the previous discussion in this thread was
> incorre
On Nov 11, 2004, at 12:59 PM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
I think that actually doesn't matter. Even in the case where we think
we can't do a full tail call optimization (because of a continuation
that's been taken), we can still actually remove the calling frame
At 10:26 PM +0100 11/11/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 11:54 AM -0800 11/11/04, Jeff Clites wrote:
On Nov 11, 2004, at 11:24 AM, Dan Sugalski wrote:
I only skimmed the earlier parts of this, but continuations
shouldn't affect tail calls at all.
You should re
On Thu, 11 Nov 2004 21:59:06 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Above is *without* tail calls. The next one was with tail calls, and it
> obviously did succeed, because tail calls do not contribute to any kind
> of stack depth. So there is for sure no limit. It's the same as an
> i
At 10:13 PM +0100 11/11/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 7:26 PM +0100 11/11/04, Leopold Toetsch wrote:
Patch is probably ready tomorrow.
Cool. I think I'd like to skip having to specify the -Oc flag,
though, and add explicit syntax to PIR.
Do we really nee
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Nov 11, 2004, at 9:44 AM, Michael Walter wrote:
>> On Thu, 11 Nov 2004 12:30:16 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>> Tail calls should be explicit, compile-time things.
> Nah, that's just the difference between running optimized and
> unop
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 7:26 PM +0100 11/11/04, Leopold Toetsch wrote:
>>Patch is probably ready tomorrow.
> Cool. I think I'd like to skip having to specify the -Oc flag,
> though, and add explicit syntax to PIR.
Do we really need it? Are there wicked cases, where we could
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:54 AM -0800 11/11/04, Jeff Clites wrote:
>>On Nov 11, 2004, at 11:24 AM, Dan Sugalski wrote:
>>>I only skimmed the earlier parts of this, but continuations
>>>shouldn't affect tail calls at all.
>>
>>You should read the thread then.
> Joy. That mean
At 11:54 AM -0800 11/11/04, Jeff Clites wrote:
On Nov 11, 2004, at 11:24 AM, Dan Sugalski wrote:
At 11:16 AM -0800 11/11/04, Jeff Clites wrote:
On Nov 11, 2004, at 9:44 AM, Michael Walter wrote:
On Thu, 11 Nov 2004 12:30:16 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
Even further, it's necessar
On Nov 11, 2004, at 11:24 AM, Dan Sugalski wrote:
At 11:16 AM -0800 11/11/04, Jeff Clites wrote:
On Nov 11, 2004, at 9:44 AM, Michael Walter wrote:
On Thu, 11 Nov 2004 12:30:16 -0500, Dan Sugalski <[EMAIL PROTECTED]>
wrote:
Even further, it's necessary for some languages
(Scheme)/paradigms (loop
At 11:16 AM -0800 11/11/04, Jeff Clites wrote:
On Nov 11, 2004, at 9:44 AM, Michael Walter wrote:
On Thu, 11 Nov 2004 12:30:16 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
Tail calls should be explicit, compile-time things. Otherwise we're
going to run afoul of traceback requirements and suchlike
At 7:26 PM +0100 11/11/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Tail calls should be explicit, compile-time things. Otherwise we're
going to run afoul of traceback requirements and suchlike things,
Yep. So is it implemented:
* tailcall / tailcallmethod opcodes
* the form
On Nov 11, 2004, at 9:44 AM, Michael Walter wrote:
On Thu, 11 Nov 2004 12:30:16 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
Tail calls should be explicit, compile-time things. Otherwise we're
going to run afoul of traceback requirements and suchlike things
Nah, that's just the difference between
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Tail calls should be explicit, compile-time things. Otherwise we're
> going to run afoul of traceback requirements and suchlike things,
Yep. So is it implemented:
* tailcall / tailcallmethod opcodes
* the former is currently created by imcc with "parrot -
On Thu, 11 Nov 2004 12:30:16 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Tail calls should be explicit, compile-time things. Otherwise we're
> going to run afoul of traceback requirements and suchlike things, and
> I think that's just not worth the risk and hassle. Besides, it's a
> lot easier
At 1:24 AM -0800 11/11/04, Jeff Clites wrote:
On Nov 10, 2004, at 11:53 PM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
This OTOH is meaning that we can do the
check only at runtime. Thus the C or C opcodes
have to do plain calls if they detect such a situation.
Yep, although the
Jeff Clites <[EMAIL PROTECTED]> wrote:
> I was thinking: Implementing tail calls seems easy;
I thought that too. So I did it ;)
$ time parrot -j fact.imc 1 # [1]
maximum recursion depth exceeded
$ time parrot -Oc -j fact.imc 1 >2# [2]
real0m0.635s
$ ti
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Nov 10, 2004, at 11:53 PM, Leopold Toetsch wrote:
[ refcounting continuations ]
>> That's really not needed. If you return from the function and you call
>> it next time, you've again a RetContinuation. If the continuation was
>> created somewhere deep
On Nov 10, 2004, at 11:53 PM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
...it sounds like we have an easy way to tell if a "real" continuation
has a claim on the register frame, because creating such a real
continuation can mark the frame,
There is no such mark. If ctx->current_
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Nov 10, 2004, at 3:08 PM, Leopold Toetsch wrote:
> But, in a tail-call-optimization case, we don't need to call
> new_register_frame() and copy_regs()--ex hypothesi, we can re-use the
> register frame already in-place. That's a big savings--that's the
>
William Coleda <[EMAIL PROTECTED]> wrote:
> Is it sufficient to provide a mechanism for the compiler writers to indicate
> that tail call should be used? For example, I have a few cases in tcl where I
> have something like:
> ($I0,$P0) = interpret($P1)
> .return($I0,$P0)
> Where I'd be happ
On Nov 10, 2004, at 3:08 PM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
But there's one wiggle: If you've created a continuation previously
(and it still exists), then any call has to preserve the frame
Well, that's what continuations are doing. They do preserve the frame,
which
Is it sufficient to provide a mechanism for the compiler writers to indicate
that tail call should be used? For example, I have a few cases in tcl where I
have something like:
($I0,$P0) = interpret($P1)
.return($I0,$P0)
Where I'd be happy to have to write:
.return_tailcall(interpret($P1))
or s
Jeff Clites <[EMAIL PROTECTED]> wrote:
> But there's one wiggle: If you've created a continuation previously
> (and it still exists), then any call has to preserve the frame
Well, that's what continuations are doing. They do preserve the frame,
which they have taken a snapshot of. And they preser
Jeff~
On Wed, 10 Nov 2004 10:40:45 -0800, Jeff Clites <[EMAIL PROTECTED]> wrote:
> I was thinking: Implementing tail calls seems easy; the normal calling
> sequence of "do some setup, then jump" just turns into "don't bother
> with (most of) the setup, just jump". That is, don't move a new
> regis
gt; continuation was "saved". You can figure some of that out at
> compile-time (whether a regular call could have been already made), but
> you'd need runtime checks for other cases, unless you just forego a
> tail call any time you _could_ have already done a regular call (whi
call any time you _could_ have already done a regular call (which
avoids the runtime checks, but allows less actual tail calls).
Do any existing languages have both tail calls and continuations?
Scheme mandates that anything which looks like a tail call, must be
optimized as expected (other languages
27 matches
Mail list logo
