Re: [Chicken-users] SRFIs 34, 35 and 36

[Joerg F. Wittenberger]

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.