Re: [Chicken-users] catching exceptions

[F. Wittenberger]

Am Dienstag, den 29.07.2008, 04:48 -0700 schrieb Elf:
> 
> the reason for the incompatibilities is that chicken uses the srfi-12 
> exception model, not the srfi-34, as the srfi-12 model is cleaner,
> more flexible, and doesnt require six other srfis in order to work.

I'm not (yet) interested in arguing about the pro's and con's of various
exception systems.

At least not until I get the one working, which is an accepted SRFI.

I just can't believe that chicken is too weak to implement that one.



Furthermore I fail to see, which six other srfi's are needed by srfi-34.
The srfi document claims dependencies on srfi-9 and srfi-23.  But I can
see only srfi-23 ("error") being used.



The problem I do have has actually nothing to do with exception handling
and advantages of either srfi.  It has to do with some magic, which
prevents setting variables as Scheme is supposed to allow.  That might
be ok, if and only if, I can break through this fence.



BTW: once I got SRFI-34 working, I'd really be interested to learn about
your opinion and what is a) cleaner and b) more flexible in srfi-12.
I'm not religious about the exception system.  There are exactly two
reason, why I insist and going to insist on srfi-34: I) "standard is
better than better" and II) I depend on it for portability.

best regards

/Jörg

> -elf
> 
> On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote:
> 
> > Am Dienstag, den 29.07.2008, 03:21 -0700 schrieb Elf:
> >> #;1> (use srfi-34)
> >> ; loading /usr/lib/chicken/3/srfi-34.scm ...
> >> ; loading /usr/lib/chicken/3/syntax-case.so ...
> >> ; loading /usr/lib/chicken/3/syntax-case-chicken-macros.scm ...
> >> ; loading library srfi-18 ...
> >> #;2> (print (guard (ex (else 'success)) (with-input-from-string ")" read)))
> >> success
> >> #;3> (condition-case (with-input-from-string ")" read) (val () "no prob"))
> >> "no prob"
> >> #;4> (condition-case (call-with-input-string ")" read) (val () "no prob"))
> >> "no prob"
> >> #;5>
> >>
> >> wasnt srfi-34.
> >
> > True.  Was the old version of srfi-34, which I could not get replaced
> > because of some network errors and probably some confusion on my part.
> >
> > Those - and my workaround - revealed some confusion wrt. chicken related
> > resources: I fetched manually
> > http://www.call-with-current-continuation.org/eggs/srfi-34.egg
> > This is still version 0.1 at this time.
> >
> > chicken-setup - which refused to download last time (yesterday I think)
> > - now finds version 0.2 as changed by Elf recently.
> >
> > However version 0.2 seems non-functional too.  Though it catches
> > exceptions, which the 0.1 version prevented to catch, it failes on
> > several tests from the SRFi-34 examples.
> >
> > (print (guard (ex (else 'success)) (call-with-input-string ")" read)))
> > => success
> >
> > OK
> >
> > 1st example from srfi-34:
> >
> > (call-with-current-continuation
> > (lambda (k)
> >   (with-exception-handler (lambda (x)
> >                             (display "condition: ")
> >                             (write x)
> >                             (newline)
> >                             (k 'exception))
> >     (lambda ()
> >       (+ 1 (raise 'an-error))))))
> > PRINTS: condition: an-error
> > => exception
> >
> > chicken prints: condition: #<condition: (exn)>
> >
> > 5th example:
> >
> > (call-with-current-continuation
> > (lambda (k)
> >   (with-exception-handler (lambda (x)
> >                             (display "reraised ") (write x) (newline)
> >                             (k 'zero))
> >     (lambda ()
> >       (guard (condition
> >                ((positive? condition) 'positive)
> >                ((negative? condition) 'negative))
> >        (raise -1))))))
> > => positive
> >
> > chicken: reraised #<condition: (exn type)>
> >
> > Ergo: raise from SRFI-18 - i.e., ##sys#signal from library.scm is not
> > compatible with SRFI-34 (btw: this is obvious from the source) and needs
> > to be replaced.
> >
> > But I'm not entirely clear what the problem actually is.  To me it seems
> > to be related to my disability to change some of chickens variables as I
> > want to and apparently the chicken library.scm happens to have the same
> > problem.
> >
> > Let's see:
> >
> > (condition-case
> > (with-exception-handler
> >  (lambda (ex) (print "Toplevelhandler: " ex))
> >  (lambda ()
> >    ((current-exception-handler) 1)))
> > (var () (print "Backstop: " var)))
> > prints: Toplevelhandler: 1
> >
> > (condition-case
> > (with-exception-handler
> >  (lambda (ex) (print "Toplevelhandler: " ex))
> >  (lambda ()
> >    (raise 1)))
> > (var () (print "Backstop: " var)))
> >
> > Loops printing: Toplevelhandler: #<condition: (exn)>
> >
> > Assembling the relevant definitions from chicken's source we find:
> >
> > srfi-18.scm:
> >
> > (define raise ##sys#signal)
> >
> > library.scm:
> >
> > (define (##sys#signal x)
> >  (##sys#current-exception-handler x) )
> >
> > (define (with-exception-handler handler thunk)
> >  (let ([oldh ##sys#current-exception-handler])
> >    (##sys#dynamic-wind
> >     (lambda () (set! ##sys#current-exception-handler handler))
> >     thunk
> >     (lambda () (set! ##sys#current-exception-handler oldh)) ) ) )
> >
> > (define (current-exception-handler) ##sys#current-exception-handler)
> >
> > This is where I can't follow.  To my understanding (raise 1) and
> > ((current-exception-handler) 1) are supposed to be equivalent.
> > Apparently I'm wrong on that one, since they are not.
> >
> > Judging from the source, I tried:
> >
> > (with-exception-handler
> >  (lambda (ex) (print "Toplevelhandler: " ex))
> >  (lambda ()
> >    (raise (make-property-condition 'testcondition))))
> >
> > since I'd expect that to go unchanged though the
> > ##sys#current-exception-handler but it doesn't help and I don#t know
> > where my testcondition get's converted into #<condition: (exn)> - which
> > is what happens.
> >
> > I wan't be able to fix that one, since I do not understand what's going
> > on.
> > Let's use
> >
> > (define (raise obj)
> >  ((current-exception-handler) obj))
> >
> > for the time being and continue to test for srfi-34 compliance.  Example
> > #7:
> >
> > (with-exception-handler
> > (lambda (ex) (print "Toplevelhandler:" ex))
> > (lambda ()
> >   (call-with-current-continuation
> >    (lambda (k)
> >      (with-exception-handler
> >       (lambda (x)
> >      (display "reraised ") (write x) (newline)
> >      (k 'zero))
> >       (lambda ()
> >      (guard (condition
> >              ((positive? condition) 'positive)
> >              ((negative? condition) 'negative))
> >             (raise 0))))))))
> > PRINTS: reraised 0
> > => zero
> >
> > chicken: does not print anything, hangs in a tight loop (since the
> > exceptionhandler in effect while evaluating the guard handler is the
> > same as during guard's body, which is wrong.
> >
> > Summary: I'm afraid srfi-34.egg is not yet ready for the prime time.
> >
> > I appreciate either a fixed version or *any* help and pointers to get me
> > going to fix it.
> >
> > best regards
> >
> > /Jörg
> >
> --2118423341-561309&#0;