chicken-users
[Top][All Lists]
Advanced

[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: 27 Feb 2003 11:18:33 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)

Unfortunately my DSL line is broken since two days and no idea how
long it's going to take.  So I can't read and dunno what's on the list
now.  Please excuse if this posting became obsolete.

William Annis <address@hidden> writes:

>  >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 whole idea of condition-type defining macros a la ML is not my
>  >idea of the "Scheme Way" (of which exist about as many as Scheme
>  >implementors ;-).
> 
>         Well, I don't particularly care which one is available, though
> I favor accepted standards by instinct when I have nothing else to go
> on.  I just want more flexibility in error handling and reporting than
> dynamic-wind offers.

Same here.

>         It looks like only SISC currently surrorts 34, or the SRFI
> implementations page hasn't been updated in a while.

rscheme has support in cvs, but it's neither well testet nor "native",
i. E. it's simplitic implemented using macro definitions on top of the
native error handling.

>  >> SRFI 36, which requires conditions for I/O operations will take more
>         I'll have to dig into that more.  My python programs are
> regularly full of exception handling code, and I'm fond of that
> model.  Bare scheme is a horror if your program ever talks to a file.
> So much can go wrong!

Actually I feel that no scheme program should be cluttered with error
handling code just for talking to a file.  I'm not sure what you refer
to with "so much can go wrong"; yes some things can, but it's not too
many (?) and I expect the Scheme system to cope with all but fatal
errors.

-- 
The worst of harm may often result from the best of intentions.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]