Kevin Ryde <[EMAIL PROTECTED]> writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>>
>> The spec for catch's pre-unwind-handler would be that it can exit
>> either normally or non-locally. If it exits normally, Guile unwinds
>> (dynamic context + stack) and then calls the normal (post-unwind)
>> h
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> The spec for catch's pre-unwind-handler would be that it can exit
> either normally or non-locally. If it exits normally, Guile unwinds
> (dynamic context + stack) and then calls the normal (post-unwind)
> handler. If it exits non-locally, that exit det
Kevin Ryde <[EMAIL PROTECTED]> writes:
> ;; lazy-catch, but with HANDLER allowed to return
> (define-public (c-lazy-catch key thunk handler)
> (catch 'c-lazy-catch
> (lambda ()
> (lazy-catch key thunk
> (lambda args
> (t
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> an example?
(c-lazy-catch #t
(lambda ()
(mucho hairy data download using http, including continuations
to suspend))
(lambda args
(print-message "%s and %s went wrong" ...)
;; continue on connection or h
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>>
>> The difference is that the enclosing call approach allows
>> code inbetween the lazy-catch and the error point to decide on a
>> different, more local strategy for handling the error, whereas the
>> hook approac
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> The difference is that the enclosing call approach allows
> code inbetween the lazy-catch and the error point to decide on a
> different, more local strategy for handling the error, whereas the
> hook approach doesn't. I think it's clear that the enclosi
>> Hmm, what I'm trying to say here that "lazy" is not some standard,
>> established terminology, and if we come up with something better, we
>> should feel free to change terminology.
>
> Yes, that makes good sense. I can't think of anything better than
> "pre-unwind", so I'll use that in all new
Marius Vollmer <[EMAIL PROTECTED]> writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>> The main part of this patch is appended below, and I would appreciate
>> any comments that anyone may have
>
> Looks very good to me. Please go ahead. Thanks!
Great; thanks for the review.
> One (minor?)
Neil Jerram <[EMAIL PROTECTED]> writes:
> The main part of this patch is appended below, and I would appreciate
> any comments that anyone may have
Looks very good to me. Please go ahead. Thanks!
One (minor?) point I have is the term "lazy". I am not sure if it is
the right term to use. It
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Yes, but internally, there is necessarily some form of `lazy-catch',
Not exactly, no.
> i.e., there is code that executes just after the exception was raised
> and just before the stack is unwound.
Yes, there is such code, but this is just part of w
Neil Jerram <[EMAIL PROTECTED]> writes:
> Theoretically, perhaps. But if you accept the gist of my analysis,
> that would be to build something that has nice clear semantics (catch)
> on top of something that has rather awkward semantics (lazy-catch),
> which doesn't seem sensible.
Yes, but inte
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Hi,
>
> Better late than never... ;-)
Absolutely!
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>> Another (lesser) problem with lazy-catch and with-exception-handler is
>> that they are always used in practice in a particular pattern. [...]
>
> OTOH,
Hi,
Better late than never... ;-)
Neil Jerram <[EMAIL PROTECTED]> writes:
> Another (lesser) problem with lazy-catch and with-exception-handler is
> that they are always used in practice in a particular pattern. For
> lazy-catch the pattern is
>
> (catch tag
> (lambda ()
> (lazy-ca
Neil Jerram <[EMAIL PROTECTED]> writes:
> We can solve both problems by merging the semantics of catch and
> lazy-catch into a single form, an enhanced catch:
>
> -- Scheme Procedure: catch key thunk handler [lazy-handler]
The main part of this patch is appended below, and I would appreciate
any
Neil Jerram <[EMAIL PROTECTED]> writes:
> I think the only really good fix for this would be to implement an
> exception handling mechanism that doesn't rely on lazy catch, along
> the lines of SRFI-34.
On second thoughts, after rereading SRFI-34, I don't think that's the
solution. SRFI-34's wit
15 matches
Mail list logo
