On Wed 09 Jan 2013 03:07, Alex Shinn <alexshinn@gmail.com> writes:

>     Secondly, its presence prohibits useful behaviors.  For example, it
>     would be easy to make a `call-with-port' that closes its port on
>     exceptional exits by installing a throw handler.  However, since
>     throw
>     handlers are also used for raise-continuable, this is not possible.
>
> Releasing resources can be done manually at the programmer
> level with their own exception handlers, even wrapping common
> patterns such as `call-with-port/close-on-exception'.

My point is precisely that you cannot implement this behavior when
raise-continuable follows the same dispatch as raise.  Imagine:

  (with-throw-handler
    (lambda (ex) #t)
    (lambda ()
      (call-with-port/do-the-right-thing p
        (lambda (p)
          (raise-continuable 1)
          (port-closed? p))))

What definition of call-with-port/do-the-right-thing will actually leave
the port open after the raise-continuable?

> Guardians also allow for easy and arbitrary finalization.

Please.  Relying on GC to run (and thus adding ports to guardians) is
not a solution in cases of limited resources like file descriptors.

> Ports in particular should be closed automatically on GC, and
> out-of-file-descriptor errors should trigger GC.

Yes, but the overhead of this is significantly higher in terms of pause
times.  I've always found that "call (gc)" is the wrong answer.

Anyway I don't think we will agree here.  I think the R7RS is making the
wrong choice.

Andy
--
http://wingolog.org/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports