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�