Re: about coroutines

[Keith Wright]

> From: Marius Vollmer <address@hidden>
> Keith Wright <address@hidden> writes:
> 
mvo> Ok, here is what I've found.
mvo> 
mvo> It's a real conservative GC bug,

I'm sorry to read that.  I was working on the easy way out, which
was to prove that the example coroutines-test was not valid Scheme,
because it did unbounded non-tail-recursive calls.  But I've
nearly convinced myself that it is valid.  (But confusing.)

mvo> and it's impossible to fix (without going to a precise GC or
mvo> non-copying continuations) since it is all over the place.

Of course the important question is not how many copies there
are, but why they are there.

mvo> The continuations stick in a stack slot that is not associated
mvo> with any variable, it's just debris from a previous function call
mvo> (specifically, from building the lexical environment of
mvo> call-with-current-continuation).

This seems a little odd.  If a memory location is not associated
with any variable, why is it on the stack?  It must be something!
Maybe the stack is being pushed before it needs to be, by adding
to the stack pointer without initializing the new stack, to make
room for temporaries that aren't really needed yet?

Conservative GC needs a little help from the C compiler that is not
strictly required for C.  There is nothing in the C spec that says the
compiler may not make copies of stuff that will never be used again,
and stick them all over the place.  We mostly trust that the compiler
will not want to do that.  I wonder if Guile acts the same way on this
example when it has been compiled with a different compiler or
different opitimization.  For example, the C spec requires
uninitialized variables to be zero, and in this case we really want
that to be true, but I can imagine an "optimization" that left
the variables uninitialized because they are "dead" and will not
be used until after an assignment.  That could cause a lot of
trouble here.

mvo> I don't know.  The continuation is referenced from a cons cell that
mvo> was passed as an argument to a function.  After that particular piece
mvo> of code (eval.c:2906), 

Is that a line number?  In my version of eval it doesn't seem to
point to anything interesting.

mvo> the stack slot that I was watching contained the reference to the
mvo> cons cell, and it didn't get cleared before the stack was copied.

mvo> One-shot continuations should make for a nice SRFI, actually.
> > 
> > Ouch.  I don't think so.
> 
mvo> Hmm, well, scratch the part about "we could even avoid...",

Already scratched, unless somebody digs it out of old mail.  I did
not understand it, did not quote it, and none of what I said was
meant to apply to it.

mvo> I was thinking too fast there.  But in general, why don't you
mvo> think so?

Well, Ouch! is not a reasoned argument either, just a reflex reaction.

RnRS> Programming languages should be designed not by piling feature
RnRS> on top of feature, but by removing the restrictions that make
RnRS> additional features appear necessary.

We already have throw with catch and lazy-catch for continuations
that are used only in restricted situations, and coop-threads seem
like coroutines by any other name.  I'm just not happy to see more
half done continuations.

Why would somebody who had full continuations working want one-shots?
A SRFI that basically says "let's throw out call/cc and replace it
with call/one-shot/cc" doesn't seem likely to get a lot of support.
One that says "let's make two different versions of call/cc, each
half-broken in different ways" is even worse.

It's hard to have too much opinion about something that isn't written
yet, but I think it might be hard to write.  Since continuation are
like procedures, equality (or eq?-ity) is not defined.  How can you
tell if you called it twice if you don't know if it's the same as
the last one?

-- 
     -- Keith Wright  <address@hidden>

Programmer in Chief, Free Computer Shop <http://www.free-comp-shop.com>
         ---  Food, Shelter, Source code.  ---