This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Maciej Stachowiak writes: > > aarchiba@calum.csclub.uwaterloo.ca writes: > > Telford Tendys <telford@triangle.triode.net.au> writes: > > > > > > Guile currently implements its error handling with exceptions; these > > > > are a very restrictive form of call/cc. There is an explanation of > > > > this in the docs. Basically, they're more efficient than call/cc. > > > > > > Are you talking speed efficient or memory efficient? > > > > Both, to some extent. Here's the story: call/cc is implemented > > essentially by copying the stack. This is expensive but necessary > > because you might continue the same way many times, from anywhere. > > ISTR there have been thread systems implemented using call/cc. > > Exceptions, OTOH, just need to be able to unwind the stack (and call > > dyn-winds). So they don't have to make a stack copy. > > > > That's how Guile does it, in particular to help it interoperate with C > code nicely. Using a very different implementation strategy, call/cc > can be a small constant cost and invoking a continuation can be > essentially a jump that passes a value. Doing things that way makes it > much harder to integrate with C, though. So call-with-current-continuation can only be unexpensive in scheme implemen- tations that are not based on a C-written library, but implement themselves? Klaus Schilling