[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] SRFIs 34, 35 and 36
From: |
Joerg F. Wittenberger |
Subject: |
Re: [Chicken-users] SRFIs 34, 35 and 36 |
Date: |
28 Feb 2003 14:08:25 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) |
Felix Winkelmann <address@hidden> writes:
> Joerg F. Wittenberger wrote:
> >
>
> >> >To be frank, I don't particularly like SRFI-34. The semantics of `raise'
> >> >are (IMHO) unnecessarily complicated, and
> > Could you please expand a little what the compliaction is? It could
>
> > be that I failed to see things.
>
> The `guard' form is specified in such a way that the exception
> is re-raised (risen?) when no clause applies, in the same dynamic
> environment /but with the exception-handler of the guard form/.
Hm. I'm not particular sure whether the implementation I just sent,
when your comment arrived handles this properly.
> I'm not particularly sure how this should be done, and I find the
> reference implementation rather confusing. But perhaps we can
> handle it in a more low-level way.
> Another point is that the difference between SRFI-18 raise and the
> one in SRFI-34 has not been completely settled, yet (If I understand
> the discussion on the SRFI-34 mailing list correctly), apparently
> a compatibility comment has been removed after that issue - so it
> looks like their incompatible.
Ups, I'm sorry, I did not follow any of the discussions. Neither did
I had the reference implementation at hand and now I better move to
real world problems...
At least now I see where this unsafe feeling came from. Comparing
SRFI 18 I think they really are incompatible.
Hm.
Maybe the SRFI 34 version should have been called 'escape'. A'la
'escape' 'raise's it's argument with the current-exception-handler
bound to the exception-handler in place when the
current-exception-handler was installed? - Just drops out of the
brain.
> It's not that I'm completely opposed to SRFI-34/35/36. It's certainly
> better than nothing.
>
> I will extend the current exception system to provide a more
> find-grained hierarchy of exception kinds than we have currently.
> Perhaps we can devise a convenient `case'-like macro that dispatches
> on contition types.
Reads a bit like the rscheme way:
(handler-case body (((<class>) handle-expr ...)
((<otherclass>) handle-expr ...)))
/Jörg
--
The worst of harm may often result from the best of intentions.