Re: continuation efficiency

[Marius Vollmer]

address@hidden (Thomas Bushnell, BSG) writes:

> In the real world, we are implementing a network protocol.  Closing
> the port is not something we do "when we are finished with it"; it's
> a protocol operation, and it's illegal to close it when the
> transaction isn't done.  Closing is like writing "RCTP to:
> <address@hidden>" on the port.  You can't just do it willy-nilly, you have
> to do it once, at the right time.

Which could be seen as an argument to not let the GC determine the
time of closing it.

> [...] Instead, the correct thing is for the *proc* routine to close
> the port *correctly* upon an error exit, which is something that you
> only know how to do in general if you know what the protocol is
> being spoken.

Yes, agreed.

> The danger supposedly avoided by using unwind-protect (in Lisp) or
> dynamic-wind (in Scheme) around the call to proc is that an error
> will happen, we'll totally abandon proc, and then the port will be
> "left open" forever and needlessly.  That's a fake worry.  A correct
> system will gc the port object as soon as this happens, if indeed,
> we have totally abandoned proc.

That would be a new requirement for the GC: to reclaim resources
at the earliest point in time when they are no longer in use.

> Now that closes the port, freeing the remote resources.  But it
> violates the protocol.  If you want to honor the protocol, then you
> need to add a finalizers option to the procedure make-remote-port.
> Again, this is all only necessary because make-remote-port is being
> specified ahead of time as being broken: as being something that holds
> magic non-gc'd resources.

I don't agree that it is broken.  I do think that not all resources
can realistically be made gc-able.  It would be good if they could,
but I am unconvinced that this is possible.

Furthermore, it disturbs me that the presence of call/cc in the
language means that some code can not be sure that its dynamic extent
has ended other than reducing the usefulness of call/cc globally.

> Can you give an example where call/ec and escape-protect are needed
> where you are *not* positing in advance that the gc system is
> broken?

The GC system is not broken, in my view.  Or rather, I am not
convinced yet that it can be fixed, if we declare it broken.


Anyway, there isn't immediate danger that I'll add call/ec and
escape-protect to the language any time soon, or without testing the
idea on comp.lang.scheme, or even in an SRFI.